RFC1036 日本語訳

Network Working Group                                          M. Horton
Request for Comments:  1036                       AT&T Bell Laboratories
Obsoletes: RFC-850                                              R. Adams
                                              Center for Seismic Studies
                                                           December 1987

コメントを求めるワーキンググループM.ホートン要求をネットワークでつないでください: 大西洋標準時1036とTベル研究所は以下を時代遅れにします。 地震の研究1987年12月へのRFC-850R.アダムスセンター

              Standard for Interchange of USENET Messages

USENETメッセージの置き換えにおいて、標準です。

STATUS OF THIS MEMO

このメモの状態

    This document defines the standard format for the interchange of
    network News messages among USENET hosts.  It updates and replaces
    RFC-850, reflecting version B2.11 of the News program.  This memo is
    disributed as an RFC to make this information easily accessible to
    the Internet community.  It does not specify an Internet standard.
    Distribution of this memo is unlimited.

このドキュメントはネットワークNewsメッセージの置き換えのためにUSENETホストの中で標準書式を定義します。 NewsプログラムのバージョンB2.11を反映して、それは、RFC-850をアップデートして、取り替えます。 このメモは、この情報を容易にインターネットコミュニティにアクセスしやすくするようにRFCとしてdisributedされます。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

1.  Introduction

1. 序論

    This document defines the standard format for the interchange of
    network News messages among USENET hosts.  It describes the format
    for messages themselves and gives partial standards for transmission
    of news.  The news transmission is not entirely in order to give a
    good deal of flexibility to the hosts to choose transmission
    hardware and software, to batch news, and so on.

このドキュメントはネットワークNewsメッセージの置き換えのためにUSENETホストの中で標準書式を定義します。 それは、メッセージ自体のために形式について説明して、ニュースの伝達の部分的な規格を与えます。 ニュース放送は完全にトランスミッションハードウェアとソフトウェアを選ぶために多くの柔軟性をホストに与えるそうではありません、バッチニュースなどに。

    There are five sections to this document.  Section two defines the
    format.  Section three defines the valid control messages.  Section
    four specifies some valid transmission methods.  Section five
    describes the overall news propagation algorithm.

このドキュメントへの5つのセクションがあります。 セクションtwoはフォーマットを定義します。 セクションthreeは有効なコントロールメッセージを定義します。 セクションfourはいくつかの有効な透過法を指定します。 セクションfiveは総合的なニュース伝播アルゴリズムを説明します。

2.  Message Format

2. メッセージ・フォーマット

    The primary consideration in choosing a message format is that it
    fit in with existing tools as well as possible.  Existing tools
    include implementations of both mail and news.  (The notesfiles
    system from the University of Illinois is considered a news
    implementation.)  A standard format for mail messages has existed
    for many years on the Internet, and this format meets most of the
    needs of USENET.  Since the Internet format is extensible,
    extensions to meet the additional needs of USENET are easily made
    within the Internet standard.  Therefore, the rule is adopted that
    all USENET news messages must be formatted as valid Internet mail
    messages, according to the Internet standard RFC-822.  The USENET
    News standard is more restrictive than the Internet standard,

メッセージ・フォーマットを選ぶことにおける第一の考慮は既存のツールとできるだけよく合ったということです。 既存のツールはメールとニュースの両方の実現を含んでいます。 (イリノイ大学からのnotesfilesシステムはニュース実現であると考えられます。) メール・メッセージのための標準書式はインターネットの何年間も存在しています、そして、この形式はUSENETの需要の大部分を満たします。 インターネット形式が広げることができるので、インターネット標準の中で容易にUSENETの追加需要を満たす拡大をします。 したがって、有効なインターネットメール・メッセージとしてすべてのUSENETニュースメッセージをフォーマットしなければならないという規則は採用されます、インターネット標準RFC-822によると。 USENET News規格はインターネット標準より制限しています。

Horton & Adams                                                  [Page 1]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[1ページ]RFC1036規格

    placing additional requirements on each message and forbidding use
    of certain Internet features.  However, it should always be possible
    to use a tool expecting an Internet message to process a news
    message.  In any situation where this standard conflicts with the
    Internet standard, RFC-822 should be considered correct and this
    standard in error.

あるインターネット機能の各メッセージと険しい使用に関する追加要件を置きます。 しかしながら、ニュースメッセージを処理するインターネットメッセージを予想するツールを使用するのはいつも可能であるべきです。 この規格がインターネット標準と衝突して、RFC-822が正しいと考えられるべきであるどんな状況と間違いこの規格でも。

    Here is an example USENET message to illustrate the fields.

ここに、分野を例証する例のUSENETメッセージがあります。

              From: jerry@eagle.ATT.COM (Jerry Schwarz)
              Path: cbosgd!mhuxj!mhuxt!eagle!jerry
              Newsgroups: news.announce
              Subject: Usenet Etiquette -- Please Read
              Message-ID: <642@eagle.ATT.COM>
              Date: Fri, 19 Nov 82 16:14:55 GMT
              Followup-To: news.misc
              Expires: Sat, 1 Jan 83 00:00:00 -0500
              Organization: AT&T Bell Laboratories, Murray Hill

From: jerry@eagle.ATT.COM (ジェリー・シュワーツ)経路: cbosgd!mhuxj!mhuxt!ワシ!jerryニュースグループ: news.announce Subject: Usenetエチケット--Message IDを読んでください: <642@eagle.ATT.COM>日付: 金曜日、1982年11月19日のグリニッジ標準時16時14分55秒Followup-To: news.misc Expires: 土曜日、1983年1月1日の00:00:00 -0500組織: AT&Tベル研究所、マリー・ヒル

              The body of the message comes here, after a blank line.

メッセージ欄は空白行の後にここに来ます。

      Here is an example of a message in the old format (before the
      existence of this standard). It is recommended that
      implementations also accept messages in this format to ease upward
      conversion.

ここに、古い方式(この規格の存在の前の)にはメッセージに関する例があります。 また、実現が上向きの変換を緩和するためにこの形式でメッセージを受け入れるのは、お勧めです。

               From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
               Newsgroups: news.misc
               Title: Usenet Etiquette -- Please Read
               Article-I.D.: eagle.642
               Posted: Fri Nov 19 16:14:55 1982
               Received: Fri Nov 19 16:59:30 1982
               Expires: Mon Jan 1 00:00:00 1990

From: cbosgd!mhuxj!mhuxt!ワシ!jerry(ジェリー・シュワーツ)ニュースグループ: news.misc Title: Usenetエチケット--記事I.D.を読んでください: .642Postedにイーグルであがってください: 1982年11月19日金曜日16時14分55秒は受けました: 1982年11月19日金曜日16時59分30秒は期限が切れます: 1月1日月曜日の00:00:00 1990

               The body of the message comes here, after a blank line.

メッセージ欄は空白行の後にここに来ます。

      Some news systems transmit news in the A format, which looks like
      this:

いくつかのニュースシステムがA形式でニュースを伝えます:(形式はこれに似ています)。

                Aeagle.642
                news.misc
                cbosgd!mhuxj!mhuxt!eagle!jerry
                Fri Nov 19 16:14:55 1982
                Usenet Etiquette - Please Read
                The body of the message comes here, with no blank line.

お願いします、Read。Aeagle.642news.misc cbosgd!mhuxj!mhuxt!ワシ!jerry1982年11月19日金曜日16時14分55秒Usenet Etiquette--、メッセージ欄はここに来ます、空白行なしで。

    A standard USENET message consists of several header lines, followed
    by a blank line, followed by the body of the message.  Each header

標準のUSENETメッセージはメッセージ欄があとに続いた空白行があとに続いたいくつかのヘッダー線から成ります。 各ヘッダー

Horton & Adams                                                  [Page 2]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[2ページ]RFC1036規格

    line consist of a keyword, a colon, a blank, and some additional
    information.  This is a subset of the Internet standard, simplified
    to allow simpler software to handle it.  The "From" line may
    optionally include a full name, in the format above, or use the
    Internet angle bracket syntax.  To keep the implementations simple,
    other formats (for example, with part of the machine address after
    the close parenthesis) are not allowed.  The Internet convention of
    continuation header lines (beginning with a blank or tab) is
    allowed.

線はキーワード、コロン、空白、および何らかの追加情報から成ります。 これは、より簡単なソフトウェアがそれを処理するのを許容するために簡素化されたインターネット標準の部分集合です。 “From"線は、上の形式でフルネームを任意に含んでいるか、またはインターネット角ブラケット構文を使用するかもしれません。 実現を簡単に保つために、他の形式(例えば近い挿入句の後の機械語アドレスの一部で)は許容されていません。 継続ヘッダー線(空白かタブで、始まる)のインターネットコンベンションは許容されています。

    Certain headers are required, and certain other headers are
    optional.  Any unrecognized headers are allowed, and will be passed
    through unchanged.  The required header lines are "From", "Date",
    "Newsgroups", "Subject", "Message-ID", and "Path".  The optional
    header lines are "Followup-To", "Expires", "Reply-To", "Sender",
    "References", "Control", "Distribution", "Keywords", "Summary",
    "Approved", "Lines", "Xref", and "Organization".  Each of these
    header lines will be described below.

確信しているヘッダーが必要です、そして、他の確信しているヘッダーは任意です。 どんな認識されていないヘッダーも、許容されていて、変わりがない状態で通り抜けるでしょう。 必要なヘッダー線は、“From"と、「日付」と、「ニュースグループ」と、「対象」と、「Message ID」と、「経路」です。 任意のヘッダー線がそうである、「追跡、-、」、「期限が切れる」、「答え」、「送付者」、「参照」、「コントロール。」「分配」、「承認された」「概要」という「キーワード」「線」、"Xref"、および「組織」 それぞれのこれらのヘッダー線は以下で説明されるでしょう。

2.1.  Required Header lines

2.1. 必要なHeader線

2.1.1.  From

2.1.1. from

    The "From" line contains the electronic mailing address of the
    person who sent the message, in the Internet syntax.  It may
    optionally also contain the full name of the person, in parentheses,
    after the electronic address.  The electronic address is the same as
    the entity responsible for originating the message, unless the
    "Sender" header is present, in which case the "From" header might
    not be verified.  Note that in all host and domain names, upper and
    lower case are considered the same, thus "mark@cbosgd.ATT.COM",
    "mark@cbosgd.att.com", and "mark@CBosgD.ATt.COm" are all equivalent.
    User names may or may not be case sensitive, for example,
    "Billy@cbosgd.ATT.COM" might be different from
    "BillY@cbosgd.ATT.COM".  Programs should avoid changing the case of
    electronic addresses when forwarding news or mail.

“From"線はインターネット構文によるメッセージを送った人の電子郵送先住所を含んでいます。 また、それは電子アドレスの後に括弧に任意に人のフルネームを保管するかもしれません。 電子アドレスが「送付者」ヘッダーが出席していない場合メッセージを溯源するのに原因となる実体と同じである、その場合、“From"ヘッダーは確かめられないかもしれません。 すべてのホストとドメイン名では、大文字と小文字が同じように考えられるというメモ、その結果、" mark@cbosgd.ATT.COM "、" mark@cbosgd.att.com "、および" mark@CBosgD.ATt.COm "はすべて同等です。 ユーザ名が大文字と小文字を区別しているかもしれない、例えば、" Billy@cbosgd.ATT.COM "は" BillY@cbosgd.ATT.COM "と異なっているかもしれません。 プログラムは、ニュースかメールを転送するとき、電子アドレスに関するケースを変えるのを避けるはずです。

    RFC-822 specifies that all text in parentheses is to be interpreted
    as a comment.  It is common in Internet mail to place the full name
    of the user in a comment at the end of the "From" line.  This
    standard specifies a more rigid syntax.  The full name is not
    considered a comment, but an optional part of the header line.
    Either the full name is omitted, or it appears in parentheses after
    the electronic address of the person posting the message, or it
    appears before an electronic address which is enclosed in angle
    brackets.  Thus, the three permissible forms are:

RFC-822は、括弧のすべてのテキストがコメントとして解釈されることであると指定します。 インターネット・メールでは、“From"行の終わりにユーザのフルネームをコメントに置くのは一般的です。 この規格は、より堅い構文を指定します。 フルネームはしかし、コメント、ヘッダー線の任意の部分であると考えられません。 フルネームが省略されるか、メッセージを掲示している人の電子アドレスの後の括弧に現れるか、またはそれは角ブラケットに同封される電子アドレスの前に現れます。 したがって、3つの許されているフォームは以下の通りです。

Horton & Adams                                                  [Page 3]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[3ページ]RFC1036規格

              From: mark@cbosgd.ATT.COM
              From: mark@cbosgd.ATT.COM (Mark Horton)
              From: Mark Horton <mark@cbosgd.ATT.COM>

From: mark@cbosgd.ATT.COM From: mark@cbosgd.ATT.COM (マークホートン)From: Horton <mark@cbosgd.ATT.COM をマークしてください、gt。

    Full names may contain any printing ASCII characters from space
    through tilde, except that they may not contain "(" (left
    parenthesis), ")" (right parenthesis), "<" (left angle bracket), or
    ">" (right angle bracket).  Additional restrictions may be placed on
    full names by the mail standard, in particular, the characters ","
    (comma), ":" (colon), "@" (at), "!" (bang), "/" (slash), "="
    (equal), and ";" (semicolon) are inadvisable in full names.

フルネームはスペースからティルドまでどんな印刷ASCII文字も含むかもしれません、彼らがそうしないかもしれないのを除いて含有、「(「(左括弧)、」、)、」 (右括弧)、"<"(左の角ブラケット)、または">"(直角ブラケット)。 「追加制限はフルネームに関してメール規格、特にキャラクタによって課されるかもしれません」、」 (コンマ)、」、:、」 (コロン), "@"(at)、“!" (衝撃音), そして、「「/」(スラッシュ)が(同輩)と「等しい」、」、;、」 (セミコロン) 完全が命名する勧められないコネはそうですか?

2.1.2.  Date

2.1.2. 日付

    The "Date" line (formerly "Posted") is the date that the message was
    originally posted to the network.  Its format must be acceptable
    both in RFC-822 and to the getdate(3) routine that is provided with
    the Usenet software.  This date remains unchanged as the message is
    propagated throughout the network.  One format that is acceptable to
    both is:

「日付」線(以前、「掲示される」)はメッセージが元々ネットワークに掲示された日付です。 形式はgetdate(3)ルーチンにRFC-822と、そして、Usenetソフトウェアが提供される許容しているに違いありません。 メッセージがネットワーク中で伝播されるのに従って、この日付は変わりがありません。 両方に許容している1つの形式は以下の通りです。

                      Wdy, DD Mon YY HH:MM:SS TIMEZONE

Wdy、DD月曜日のYY HH:mm:SSタイムゾーン

    Several examples of valid dates appear in the sample message above.
    Note in particular that ctime(3) format:

有効な期日に関するいくつかの例がサンプルメッセージに上に現れます。 ctime(3)が以下をフォーマットすることに特に注意してください。

                          Wdy Mon DD HH:MM:SS YYYY

Wdy月曜日のDD HH:mm:SS YYYY

    is not acceptable because it is not a valid RFC-822 date.  However,
    since older software still generates this format, news
    implementations are encouraged to accept this format and translate
    it into an acceptable format.

有効なRFC-822デートの相手でないので、許容できません。 しかしながら、より古いソフトウェアがこの形式をまだ発生させているので、ニュース実現は、この形式を受け入れて、許容形式にそれを翻訳するよう奨励されます。

    There is no hope of having a complete list of timezones.  Universal
    Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST,
    CDT, EST, EDT) and the +/-hhmm offset specifed in RFC-822 should be
    supported.  It is recommended that times in message headers be
    transmitted in GMT and displayed in the local time zone.

タイムゾーンに関する全リストを持っているという望みが全くありません。 そして、世界標準時(グリニッジ標準時)、北米のタイムゾーン、(太平洋標準時であって、太平洋夏時間、MST、MDT、CST、米国東部標準時の、そして、東部夏時間のCDT)、RFC-822でspecifedされた+/-hhmmオフセットは支持されるべきです。 メッセージヘッダーの回がグリニッジ標準時に伝えられて、現地時間にゾーンを表示したのは、お勧めです。

2.1.3.  Newsgroups

2.1.3. ニュースグループ

    The "Newsgroups" line specifies the newsgroup or newsgroups in which
    the message belongs.  Multiple newsgroups may be specified,
    separated by a comma.  Newsgroups specified must all be the names of
    existing newsgroups, as no new newsgroups will be created by simply
    posting to them.

「ニュースグループ」線はメッセージが属するニュースグループかニュースグループを指定します。 コンマによって切り離されて、複数のニュースグループが指定されるかもしれません。 指定されたニュースグループはすべて、既存のニュースグループの名前であるに違いありません、どんな新しいニュースグループも単にそれらに掲示することによって創設されないとき。

Horton & Adams                                                  [Page 4]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[4ページ]RFC1036規格

    Wildcards (e.g., the word "all") are never allowed in a "News-
    groups" line.  For example, a newsgroup comp.all is illegal,
    although a newsgroup rec.sport.football is permitted.

ワイルドカード(例えば、「すべて」という単語)は「ニュースは分類する」という台詞で決して許容されていません。 例えば、ニュースグループrec.sport.footballは受入れられますが、ニュースグループcomp.allは不法です。

    If a message is received with a "Newsgroups" line listing some valid
    newsgroups and some invalid newsgroups, a host should not remove
    invalid newsgroups from the list.  Instead, the invalid newsgroups
    should be ignored.  For example, suppose host A subscribes to the
    classes btl.all and comp.all, and exchanges news messages with host
    B, which subscribes to comp.all but not btl.all.  Suppose A receives
    a message with Newsgroups: comp.unix,btl.general.

「ニュースグループ」線がいくつかの有効なニュースグループといくつかの無効のニュースグループを記載している状態でメッセージを受け取るなら、ホストはリストから無効のニュースグループを取り除くべきではありません。 代わりに、無効のニュースグループは無視されるべきです。 例えば、ホストAがクラスのbtl.allとcomp.allに加入して、ホストBとニュースメッセージを交換すると仮定してください。(そのホストは、btl.allではなく、comp.all butに加入します)。 Aがニュースグループと共にメッセージを受け取ると仮定してください: comp.unix、btl.general。

    This message is passed on to B because B receives comp.unix, but B
    does not receive btl.general.  A must leave the "Newsgroups" line
    unchanged.  If it were to remove btl.general, the edited header
    could eventually re-enter the btl.all class, resulting in a message
    that is not shown to users subscribing to btl.general.  Also,
    follow-ups from outside btl.all would not be shown to such users.

Bがcomp.unixを受けるので、このメッセージはBに通過されますが、Bはbtl.generalを受けません。 絶対に必要なものは「ニュースグループ」線を変わりがないままにします。 btl.generalを取り外すなら、編集されたヘッダーは結局btl.allのクラスに再入できるでしょうに、btl.generalに加入するユーザに示されないメッセージをもたらして。 また、btl.allの外からのフォローアップはそのようなユーザに示されないでしょう。

2.1.4.  Subject

2.1.4. 対象

    The "Subject" line (formerly "Title") tells what the message is
    about.  It should be suggestive enough of the contents of the
    message to enable a reader to make a decision whether to read the
    message based on the subject alone.  If the message is submitted in
    response to another message (e.g., is a follow-up) the default
    subject should begin with the four characters "Re:", and the
    "References" line is required.  For follow-ups, the use of the
    "Summary" line is encouraged.

「受けることがある」線(以前「タイトル」)は、メッセージが何に関するかを言います。 それは読者が対象に基づくメッセージを読むかどうかという決定を単独にするのを可能にするメッセージのコンテンツが十分思わせ振りであるべきです。 別のメッセージ(例えば、フォローアップである)に対応してメッセージを提出するなら、デフォルト対象は4つのキャラクタ「Re:」で始まるはずです、そして、「参照」線が必要です。 フォローアップにおいて、「概要」線の使用は奨励されます。

2.1.5.  Message-ID

2.1.5. Message ID

    The "Message-ID" line gives the message a unique identifier.  The
    Message-ID may not be reused during the lifetime of any previous
    message with the same Message-ID.  (It is recommended that no
    Message-ID be reused for at least two years.)  Message-ID's have the
    syntax:

「Message ID」線はユニークな識別子をメッセージに与えます。 Message-IDはどんな前のメッセージの生涯も同じMessage-IDと共に再利用されないかもしれません。 (Message-IDが全く少なくとも2年間再利用されないのは、お勧めです。) Message IDのものには、構文があります:

                     <string not containing blank or ">">

または、空白を含まない<ストリング、「>">"

    In order to conform to RFC-822, the Message-ID must have the format:

RFC-822に従うために、Message-IDには、形式がなければなりません:

                          <unique@full_domain_name>

_<のユニークな@full_ドメイン名前>。

    where full_domain_name is the full name of the host at which the
    message entered the network, including a domain that host is in, and
    unique is any string of printing ASCII characters, not including "<"
    (left angle bracket), ">" (right angle bracket), or "@" (at sign).

_完全であるところでは、ドメイン_名前がメッセージがホストがいるドメインを含むネットワークに入ったホストのフルネームです、そして、ユニークであるのが、印刷ASCII文字のあらゆるストリングです、"<"(左の角ブラケット)、">"(直角ブラケット)、または"@"(サインの)を含んでいなくて。

Horton & Adams                                                  [Page 5]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[5ページ]RFC1036規格

    For example, the unique part could be an integer representing a
    sequence number for messages submitted to the network, or a short
    string derived from the date and time the message was created.  For
    example, a valid Message-ID for a message submitted from host ucbvax
    in domain "Berkeley.EDU" would be "<4123@ucbvax.Berkeley.EDU>".
    Programmers are urged not to make assumptions about the content of
    Message-ID fields from other hosts, but to treat them as unknown
    character strings.  It is not safe, for example, to assume that a
    Message-ID will be under 14 characters, that it is unique in the
    first 14 characters, nor that is does not contain a "/".

ユニークな部分は、例えば、ネットワークに提出されたメッセージのために一連番号を表す整数、またはメッセージが作成された日時から得られた脆いストリングであるかもしれません。 「例えば、ドメイン"Berkeley.EDU"でホストucbvaxから提出されたメッセージのための有効なMessage-IDが "<4123@ucbvax.Berkeley.EDU であるだろう、gt;、」 プログラマがMessage-IDの内容に関する仮定を他のホストから分野にするのではなく、未知の文字列として彼らを扱うよう促されます。 「それがそう、例えば、Message-IDが14未満のキャラクタになって、それが最初の14のキャラクタでユニークであると仮定するそうする金庫でないのがそうしない、a」/を含んでください、」

    The angle brackets are considered part of the Message-ID.  Thus, in
    references to the Message-ID, such as the ihave/sendme and cancel
    control messages, the angle brackets are included.  White space
    characters (e.g., blank and tab) are not allowed in a Message-ID.
    Slashes ("/") are strongly discouraged.  All characters between the
    angle brackets must be printing ASCII characters.

角ブラケットはMessage-IDの一部であると考えられます。 したがって、Message-IDのihave/sendmeやキャンセルコントロールメッセージなどの参照では、角ブラケットは含まれています。 余白キャラクタ(例えば、空白とタブ)はMessage-IDに許容されていません。 スラッシュ(「/」)は強くがっかりしています。 角ブラケットの間のすべてのキャラクタがASCII文字を印刷しなければなりません。

2.1.6.  Path

2.1.6. 経路

    This line shows the path the message took to reach the current
    system.  When a system forwards the message, it should add its own
    name to the list of systems in the "Path" line.  The names may be
    separated by any punctuation character or characters (except "."
    which is considered part of the hostname).  Thus, the following are
    valid entries:

この線は、メッセージが現在のシステムに達するように取ったのを経路に案内します。 システムがメッセージを転送するとき、それは「経路」線でそれ自身の名前をシステムのリストに追加するべきです。 「名前はどんな句読文字やキャラクタによっても切り離されるかもしれません(」 . 」 ホスト名の一部であると考えられるものを除いてください)。 したがって、↓これは有効なエントリーです:

                   cbosgd!mhuxj!mhuxt
                   cbosgd, mhuxj, mhuxt
                   @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM
                   teklabs, zehntel, sri-unix@cca!decvax

cbosgd!mhuxj!@mhuxt mhuxt cbosgd、mhuxj、mhuxt@cbosgd.ATT.COM、@mhuxj.ATT.COM、.ATT.COM teklabs、zehntel、 sri-unix@cca!decvax

    (The latter path indicates a message that passed through decvax,
    cca, sri-unix, zehntel, and teklabs, in that order.) Additional
    names should be added from the left.  For example, the most recently
    added name in the fourth example was teklabs.  Letters, digits,
    periods and hyphens are considered part of host names; other
    punctuation, including blanks, are considered separators.

(後者の経路はそのオーダーをdecvax、cca、様unix、zehntel、およびteklabsを通り抜けたメッセージを示します。) 追加名前は左から加えられるべきです。 例えば、4番目の例の最も最近加えられた名前はteklabsでした。 手紙、ケタ、期間、およびハイフンはホスト名の一部であると考えられます。 空白を含む他の句読は分離符であると考えられます。

    Normally, the rightmost name will be the name of the originating
    system.  However, it is also permissible to include an extra entry
    on the right, which is the name of the sender.  This is for upward
    compatibility with older systems.

通常、一番右の名前は由来しているシステムの名前になるでしょう。 しかしながら、また、送付者の名前である右での余分なエントリーを含んでいるのも許されています。 より古いシステムでこれは上位互換性のためのものです。

    The "Path" line is not used for replies, and should not be taken as
    a mailing address.  It is intended to show the route the message
    traveled to reach the local host.  There are several uses for this
    information.  One is to monitor USENET routing for performance

「経路」線を回答に使用しないで、郵送先住所としてみなすべきではありません。 メッセージがローカル・ホストに届くように移動したのをルートに示すのは意図しています。 この情報へのいくつかの用途があります。 1つは性能のためのUSENETルーティングをモニターすることになっています。

Horton & Adams                                                  [Page 6]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[6ページ]RFC1036規格

    reasons.  Another is to establish a path to reach new hosts.
    Perhaps the most important use is to cut down on redundant USENET
    traffic by failing to forward a message to a host that is known to
    have already received it.  In particular, when host A sends a
    message to host B, the "Path" line includes A, so that host B will
    not immediately send the message back to host A.  The name each host
    uses to identify itself should be the same as the name by which its
    neighbors know it, in order to make this optimization possible.

理由。 別のものは、新しいホストに届くように経路を確立することになっています。 余分なUSENET交通のカットには恐らく最も重要な使用が、既にそれを受けたのが知られているホストにメッセージを転送しないことによって、あります。 ホストAがホストBにメッセージを送るとき、特に、「経路」線がAを含んでいるので、BがすぐにA. 各ホストがそれ自体を特定するのに使用する名前をホスティングするためにメッセージを返送しないそのホストは隣人が知っているそれの名前と同じであるべきです、この最適化を可能にするように。

    A host adds its own name to the front of a path when it receives a
    message from another host.  Thus, if a message with path "A!X!Y!Z"
    is passed from host A to host B, B will add its own name to the path
    when it receives the message from A, e.g., "B!A!X!Y!Z".  If B then
    passes the message on to C, the message sent to C will contain the
    path "B!A!X!Y!Z", and when C receives it, C will change it to
    "C!B!A!X!Y!Z".

別のホストからメッセージを受け取るとき、ホストは経路の前にそれ自身の名前を加えます。 A、例えば、「B!A!X!Y Z!」からメッセージを受け取るとき、したがって、「A!X!Y Z!」という経路があるメッセージがホストAからホストBまで通過されると、Bはそれ自身の名前を経路に加えるでしょう。 次に、BがメッセージをCに通過すると、Cに送られたメッセージは経路「B!A!X!Y Z!」を含むでしょう、そして、Cがそれを受けるとき、Cはそれを「C!B!A!X!Y Z!」に変えるでしょう。

    Special upward compatibility note:  Since the "From", "Sender", and
    "Reply-To" lines are in Internet format, and since many USENET hosts
    do not yet have mailers capable of understanding Internet format, it
    would break the reply capability to completely sever the connection
    between the "Path" header and the reply function.  It is recognized
    that the path is not always a valid reply string in older
    implementations, and no requirement to fix this problem is placed on
    implementations.  However, the existing convention of placing the
    host name and an "!"  at the front of the path, and of starting the
    path with the host name, an "!", and the user name, should be
    maintained when possible.

特別な上位互換性注意: 」 線に答えてください。そして、“From"、「送付者」、「コネはインターネット形式であり、多くのUSENETホストがまだ郵送者をインターネット形式を理解できるようにしていないので、それは「経路」ヘッダーと回答機能との関係を完全に断ち切る回答能力を壊すでしょう。 経路が、より古い実現でいつも有効な回答ストリングであるというわけではないと認められて、この問題を修正するという要件は全く実現に置かれません。 しかしながら、可能であるときに、経路の前にホスト名と“!"をみなして、ホスト名から経路を始める既存のコンベンション(“!"、およびユーザ名)は、維持されるべきです。

2.2.  Optional Headers

2.2. 任意のヘッダー

2.2.1.  Reply-To

2.2.1. 答えます。

    This line has the same format as "From".  If present, mailed replies
    to the author should be sent to the name given here.  Otherwise,
    replies are mailed to the name on the "From" line. (This does not
    prevent additional copies from being sent to recipients named by the
    replier, or on "To" or "Cc" lines.)  The full name may be optionally
    given, in parentheses, as in the "From" line.

この線には、“From"と同じ形式があります。 作者への現在の、そして、郵送された回答をここに与えられた名前に送るなら。 さもなければ、“From"線の上の名前に回答を郵送します。 (これは、複本が「再-プライヤー」の近く、または、“To"の上で指定された受取人か「cc」台詞に送られるのを防ぎません。) “From"線のように括弧で任意にフルネームを与えるかもしれません。

2.2.2.  Sender

2.2.2. 送付者

    This field is present only if the submitter manually enters a "From"
    line.  It is intended to record the entity responsible for
    submitting the message to the network.  It should be verified by the
    software at the submitting host.

submitterが手動で“From"線に入る場合にだけ、この分野は存在しています。 ネットワークにメッセージを提出するのに原因となる実体を記録するのは意図しています。 それは提出しているホストのソフトウェアによって確かめられるはずです。

Horton & Adams                                                  [Page 7]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[7ページ]RFC1036規格

    For example, if John Smith is visiting CCA and wishes to post a
    message to the network, using friend Sarah Jones' account, the
    message might read:

例えば、友人サラ・ジョーンズのアカウントを使用して、ジョン・スミスがCCAを訪問していて、ネットワークにメッセージを掲示したいなら、メッセージは読むかもしれません:

              From: smith@ucbvax.Berkeley.EDU (John Smith)
              Sender: jones@cca.COM (Sarah Jones)

From: smith@ucbvax.Berkeley.EDU (ジョン・スミス)送付者: jones@cca.COM (サラ・ジョーンズ)

    If a gateway program enters a mail message into the network at host
    unix.SRI.COM, the lines might read:

ゲートウェイプログラムがホストunix.SRI.COMでメール・メッセージをネットワークに入力するなら、線は読むかもしれません:

              From: John.Doe@A.CS.CMU.EDU
              Sender: network@unix.SRI.COM

From: John.Doe@A.CS.CMU.EDU 送付者: network@unix.SRI.COM

    The primary purpose of this field is to be able to track down
    messages to determine how they were entered into the network.  The
    full name may be optionally given, in parentheses, as in the "From"
    line.

この分野の第一の目的はそれらがどのようにネットワークに入れられたかを決定するメッセージを捜し出すことであることができます。 “From"線のように括弧で任意にフルネームを与えるかもしれません。

2.2.3.  Followup-To

2.2.3. 追跡、-

    This line has the same format as "Newsgroups".  If present, follow-
    up messages are to be posted to the newsgroup or newsgroups listed
    here.  If this line is not present, follow-ups are posted to the
    newsgroup or newsgroups listed in the "Newsgroups" line.

この線には、「ニュースグループ」と同じ形式があります。 存在しているなら、ニュースグループに掲示されることになっていてください。さもないと、ニュースグループがここに記載したというメッセージで続いてください。 この線が存在していないなら、フォローアップは「ニュースグループ」線で記載されたニュースグループかニュースグループに掲示されます。

    If the keyword poster is present, follow-up messages are not
    permitted.  The message should be mailed to the submitter of the
    message via mail.

キーワードポスターが存在しているなら、追跡しているメッセージは受入れられません。 メールでメッセージのsubmitterにメッセージを郵送するべきです。

2.2.4.  Expires

2.2.4. 期限が切れます。

    This line, if present, is in a legal USENET date format.  It
    specifies a suggested expiration date for the message.  If not
    present, the local default expiration date is used.  This field is
    intended to be used to clean up messages with a limited usefulness,
    or to keep important messages around for longer than usual.  For
    example, a message announcing an upcoming seminar could have an
    expiration date the day after the seminar, since the message is not
    useful after the seminar is over.  Since local hosts have local
    policies for expiration of news (depending on available disk space,
    for instance), users are discouraged from providing expiration dates
    for messages unless there is a natural expiration date associated
    with the topic.  System software should almost never provide a
    default "Expires" line.  Leave it out and allow local policies to be
    used unless there is a good reason not to.

存在しているなら、この線は法的なUSENET日付の形式においてそうです。 それは提案された有効期限をメッセージに指定します。 プレゼント、地方でないのがデフォルトとするなら、有効期限は使用されています。 限られた有用性でメッセージをきれいにするか、またはいつもより長い間重要なメッセージを置くのにこの分野が使用されることを意図します。 例えば、今度のセミナーを発表するメッセージはセミナーの後の日に有効期限を持っているかもしれません、セミナーが終わっていた後にメッセージが役に立たないので。ローカル・ホストにはニュース(例えば、利用可能な椎間腔に依存する)の満了のためのローカルの方針があるので、話題に関連している自然な有効期限がない場合、ユーザはメッセージのための提供有効期限からがっかりしています。 システムソフトはほとんどデフォルトが「期限が切れる」という台詞を提供するべきではありません。 それを省いてください、そして、もっともな理由がない場合、ローカルの方針は使用させられてください。

Horton & Adams                                                  [Page 8]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[8ページ]RFC1036規格

2.2.5.  References

2.2.5. 参照

    This field lists the Message-ID's of any messages prompting the
    submission of this message.  It is required for all follow-up
    messages, and forbidden when a new subject is raised.
    Implementations should provide a follow-up command, which allows a
    user to post a follow-up message.  This command should generate a
    "Subject" line which is the same as the original message, except
    that if the original subject does not begin with "Re:" or "re:", the
    four characters "Re:" are inserted before the subject.  If there is
    no "References" line on the original header, the "References" line
    should contain the Message-ID of the original message (including the
    angle brackets).  If the original message does have a "References"
    line, the follow-up message should have a "References" line
    containing the text of the original "References" line, a blank, and
    the Message-ID of the original message.

この分野はIDのこのメッセージの服従をうながすどんなメッセージのMessage-ものも記載します。 新しい対象が高くしているとき、それは、すべての追跡しているメッセージに必要であり、禁じられます。 実現は追跡しているコマンドを提供するべきです。(ユーザはそれで追跡しているメッセージを掲示できます)。 オリジナルの対象が「Re:」で始まらないなら、このコマンドはそれを除いて、オリジナルのメッセージと同じ「受けることがある」線を発生させるべきです。 または、「re:」、4つのキャラクタ「Re:」 対象の前に挿入されます。 オリジナルのヘッダーの上に「参照」線が全くなければ、「参照」線はオリジナルのメッセージのMessage-IDを含むはずです(角ブラケットを含んでいて)。 オリジナルのメッセージに「参照」線があるなら、追跡しているメッセージには、元の「参照」線、空白、およびオリジナルのメッセージのMessage-IDのテキストを含む「参照」線があるべきです。

    The purpose of the "References" header is to allow messages to be
    grouped into conversations by the user interface program.  This
    allows conversations within a newsgroup to be kept together, and
    potentially users might shut off entire conversations without
    unsubscribing to a newsgroup.  User interfaces need not make use of
    this header, but all automatically generated follow-ups should
    generate the "References" line for the benefit of systems that do
    use it, and manually generated follow-ups (e.g., typed in well after
    the original message has been printed by the machine) should be
    encouraged to include them as well.

「参照」ヘッダーの目的はユーザーインタフェースプログラムで会話に分類されるべきメッセージを許容することです。 これは、ニュースグループの中の会話が一緒に保たれるのを許容します、そして、潜在的に、ニュースグループに外さないで、ユーザは全体の会話を止めるかもしれません。 すべての自動的に発生したフォローアップがそれを使用するシステムの利益のために「参照」線を発生させるべきです、そして、ユーザインタフェースはこのヘッダーを利用する必要はありませんが、また、手動で発生しているフォローアップ(例えば、オリジナルのメッセージがマシンによって印刷された後によくタイプされる)がそれらを含んでいるよう奨励されるべきです。

    It is permissible to not include the entire previous "References"
    line if it is too long.  An attempt should be made to include a
    reasonable number of backwards references.

それが長過ぎるなら、前の全体の「参照」線を含んでいないのは許されています。 相当な数の遅れている指示するものを含んでいるのを試みをするべきです。

2.2.6.  Control

2.2.6. コントロール

    If a message contains a "Control" line, the message is a control
    message.  Control messages are used for communication among USENET
    host machines, not to be read by users.  Control messages are
    distributed by the same newsgroup mechanism as ordinary messages.
    The body of the "Control" header line is the message to the host.

メッセージが「コントロール」線を含んでいるなら、メッセージはコントロールメッセージです。 USENETホスト・マシンの中のコミュニケーションにおいて、ユーザによって読まれないように、コントロールメッセージは使用されています。 コントロールメッセージは普通のメッセージと同じニュースグループメカニズムによって分配されます。 「コントロール」ヘッダー線のボディーはホストへのメッセージです。

    For upward compatibility, messages that match the newsgroup pattern
    "all.all.ctl" should also be interpreted as control messages.  If no
    "Control" header is present on such messages, the subject is used as
    the control message.  However, messages on newsgroups matching this
    pattern do not conform to this standard.

また、上位互換性において、ニュースグループパターン"all.all.ctl"に合っているメッセージはコントロールメッセージとして解釈されるべきです。 どんな「コントロール」ヘッダーもそのようなメッセージに出席していないなら、対象はコントロールメッセージとして使用されます。 しかしながら、このパターンに合っているニュースグループに関するメッセージはこの規格に従いません。

Horton & Adams                                                  [Page 9]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[9ページ]RFC1036規格

    Also for upward compatibility, if the first 4 characters of the
    "Subject:" line are "cmsg", the rest of the "Subject:" line should
    be interpreted as a control message.

上位互換性も「Subject:」の最初の4つのキャラクタです。 線は"cmsg"、「Subject:」の残りです。 線はコントロールメッセージとして解釈されるべきです。

2.2.7.  Distribution

2.2.7. 分配

    This line is used to alter the distribution scope of the message.
    It is a comma separated list similar to the "Newsgroups" line.  User
    subscriptions are still controlled by "Newsgroups", but the message
    is sent to all systems subscribing to the newsgroups on the
    "Distribution" line in addition to the "Newsgroups" line.  For the
    message to be transmitted, the receiving site must normally receive
    one of the specified newsgroups AND must receive one of the
    specified distributions.  Thus, a message concerning a car for sale
    in New Jersey might have headers including:

この線は、メッセージの分配範囲を変更するのに使用されます。 それは「ニュースグループ」線と同様のコンマ切り離されたリストです。 「ニュースグループ」はまだユーザ購読を制御していますが、「ニュースグループ」線に加えた「分配」線の上でニュースグループに加入するすべてのシステムにメッセージを送ります。 伝えられるべきメッセージに関しては、受信サイトは、通常、指定されたニュースグループの1つを受け取らなければならなくて、指定された配の1つを受け取らなければなりません。 したがって、持っていて、:ニュージャージーの売り物の車に関するメッセージにはヘッダーがあるかもしれません。

                   Newsgroups: rec.auto,misc.forsale
                   Distribution: nj,ny

ニュースグループ: rec.auto、ミスクforsale Distribution: nj、ny

    so that it would only go to persons subscribing to rec.auto or misc.
    for sale within New Jersey or New York.  The intent of this header
    is to restrict the distribution of a newsgroup further, not to
    increase it.  A local newsgroup, such as nj.crazy-eddie, will
    probably not be propagated by hosts outside New Jersey that do not
    show such a newsgroup as valid.  A follow-up message should default
    to the same "Distribution" line as the original message, but the
    user can change it to a more limited one, or escalate the
    distribution if it was originally restricted and a more widely
    distributed reply is appropriate.

ニュージャージーかニューヨークの中の売り物のrec.autoかミスクに加入するために人々のものになるだけであるように。 このヘッダーの意図はそれを増加させるのではなく、さらにニュースグループの分配を制限することです。 nj.crazy-eddieなどの地方のニュースグループはたぶんニュージャージーの外の有効であるようなニュースグループを見せないホストによって伝播されないでしょう。 追跡しているメッセージがオリジナルのメッセージと同じ「分配」線をデフォルトとするべきですが、それが元々、制限されて、広くより分配された回答が適切であるなら、ユーザは、それをより限られたものに変えるか、または分配を徐々に拡大することができます。

2.2.8.  Organization

2.2.8. 組織

    The text of this line is a short phrase describing the organization
    to which the sender belongs, or to which the machine belongs.  The
    intent of this line is to help identify the person posting the
    message, since host names are often cryptic enough to make it hard
    to recognize the organization by the electronic address.

この線のテキストは送付者が属するか、またはマシンが属する組織について説明する短い句です。 この線の意図はメッセージを掲示している人を特定するのを助けることです、ホスト名がしばしば電子アドレスで組織を認識するのを困難にするほど不可解であるので。

2.2.9.  Keywords

2.2.9. キーワード

    A few well-selected keywords identifying the message should be on
    this line.  This is used as an aid in determining if this message is
    interesting to the reader.

この線の上にメッセージを特定するいくつかのよく選択されたキーワードがあるべきです。 読者にとって、このメッセージがおもしろいかどうか決定する際にこれは援助として使用されます。

2.2.10.  Summary

2.2.10. 概要

    This line should contain a brief summary of the message.  It is
    usually used as part of a follow-up to another message.  Again, it

この線はメッセージの簡潔な概要を含むはずです。 通常、それはフォローアップの一部として別のメッセージに使用されます。 再びそれ

Horton & Adams                                                 [Page 10]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[10ページ]RFC1036規格

    is very useful to the reader in determining whether to read the
    message.

メッセージを読むかどうか決定する際に非常に読者の役に立ちます。

2.2.11.  Approved

2.2.11. 承認されます。

    This line is required for any message posted to a moderated
    newsgroup.  It should be added by the moderator and consist of his
    mail address.  It is also required with certain control messages.

この線が加減されたニュースグループに掲示されたどんなメッセージにも必要です。 それは、議長によって加えられて、彼の郵便の宛先から成るべきです。 また、それが、あるコントロールメッセージで必要です。

2.2.12.  Lines

2.2.12. 線

    This contains a count of the number of lines in the body of the
    message.

これはメッセージ欄の線の数のカウントを含んでいます。

2.2.13.  Xref

2.2.13. Xref

    This line contains the name of the host (with domains omitted) and a
    white space separated list of colon-separated pairs of newsgroup
    names and message numbers.  These are the newsgroups listed in the
    "Newsgroups" line and the corresponding message numbers from the
    spool directory.

この線はホスト(ドメインが省略されている)の名前とコロンで切り離された組のニュースグループ名とメッセージ番号の余白の切り離されたリストを含んでいます。 これらはスプールディレクトリから「ニュースグループ」線と対応するメッセージ番号で記載されたニュースグループです。

    This is only of value to the local system, so it should not be
    transmitted.  For example, in:

これにはローカルシステムには価値しかないので、それを伝えるべきではありません。 例えば、そして、中:

               Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid
               From: reid@decwrl.DEC.COM (Brian Reid)
               Newsgroups: news.lists,news.groups
               Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86
               Message-ID: <5658@decwrl.DEC.COM>
               Date: 1 Oct 86 11:26:15 GMT
               Organization: DEC Western Research Laboratory
               Lines: 441
               Approved: reid@decwrl.UUCP
               Xref: seismo news.lists:461 news.groups:6378

経路: seismo!lll-crg!lll-lcc!ピラミッド!decwrl!reid From: reid@decwrl.DEC.COM (ブライアン・リード)ニュースグループ: news.lists、news.groups Subject: 9月86日のMessage IDのためのUSENET購読者層概略報告: <5658@decwrl.DEC. COM>日付: 1986年10月1日のグリニッジ標準時11時26分15秒の組織: 12月の西洋の研究所は立ち並びます: 441は承認しました: reid@decwrl.UUCP Xref: seismo news.lists: 461news.groups: 6378

    the "Xref" line shows that the message is message number 461 in the
    newsgroup news.lists, and message number 6378 in the newsgroup
    news.groups, on host seismo.  This information may be used by
    certain user interfaces.

"Xref"線は、メッセージがニュースグループnews.listsにおけるメッセージ番号461と、ニュースグループnews.groupsでメッセージ番号6378であることを示します、ホストseismoで。 この情報はあるユーザインタフェースによって使用されるかもしれません。

3.  Control Messages

3. コントロールメッセージ

    This section lists the control messages currently defined.  The body
    of the "Control" header line is the control message.  Messages are a
    sequence of zero or more words, separated by white space (blanks or
    tabs).  The first word is the name of the control message, remaining
    words are parameters to the message.  The remainder of the header

このセクションは現在定義されているコントロールメッセージをリストアップします。 「コントロール」ヘッダー線のボディーはコントロールメッセージです。 メッセージはゼロの系列であるか以上が余白(空白かタブ)によって切り離された単語です。 最初の単語がコントロールメッセージの名前である、残っている単語はメッセージへのパラメタです。 ヘッダーの残り

Horton & Adams                                                 [Page 11]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[11ページ]RFC1036規格

    and the body of the message are also potential parameters; for
    example, the "From" line might suggest an address to which a
    response is to be mailed.

そして、また、メッセージ欄は潜在的パラメタです。 例えば、“From"線は郵送される応答がことであるアドレスを示すかもしれません。

    Implementors and administrators may choose to allow control messages
    to be carried out automatically, or to queue them for annual
    processing.  However, manually processed messages should be dealt
    with promptly.

作成者と管理者は、自動的に行われるか、または例年の処理のためにそれらを列に並ばせるコントロールメッセージを許容するのを選ぶかもしれません。 しかしながら、手動で処理されたメッセージは即座に対処されるべきです。

    Failed control messages should NOT be mailed to the originator of
    the message, but to the local "usenet" account.

メッセージについて創始者に郵送するのではなく、ローカルの"usenet"アカウントに失敗したコントロールメッセージを郵送するべきです。

3.1.  Cancel

3.1. キャンセル

                     cancel <Message-ID>

<Message-ID>を取り消してください。

    If a message with the given Message-ID is present on the local
    system, the message is cancelled.  This mechanism allows a user to
    cancel a message after the message has been distributed over the
    network.

与えられたMessage-IDがあるメッセージがローカルシステムに存在しているなら、メッセージは取り消されます。 このメカニズムで、メッセージがネットワークの上に分配された後にユーザはメッセージを取り消すことができます。

    If the system is unable to cancel the message as requested, it
    should not forward the cancellation request to its neighbor systems.

システムが要求された通りメッセージを取り消すことができないなら、それは隣人システムに解約請求を送るべきではありません。

    Only the author of the message or the local news administrator is
    allowed to send this message.  The verified sender of a message is
    the "Sender" line, or if no "Sender" line is present, the "From"
    line.  The verified sender of the cancel message must be the same as
    either the "Sender" or "From" field of the original message.  A
    verified sender in the cancel message is allowed to match an
    unverified "From" in the original message.

メッセージの作者かローカル・ニュース管理者だけがこのメッセージを送ることができます。 メッセージの確かめられた送付者は「送付者」線であるかどんな「送付者」線も存在していないなら、“From"は立ち並んでいます。 キャンセルメッセージの確かめられた送付者はオリジナルのメッセージの「送付者」か“From"分野と同じであるに違いありません。 キャンセルメッセージの確かめられた送付者はオリジナルのメッセージでunverified “From"に合うことができます。

3.2.  Ihave/Sendme

3.2. Ihave/Sendme

                   ihave <Message-ID list> [<remotesys>]
                   sendme <Message-ID list> [<remotesys>]

ihave<Message-IDリスト>[<remotesys>]sendme<Message-IDリスト>。[<remotesys>]

    This message is part of the ihave/sendme protocol, which allows one
    host (say A) to tell another host (B) that a particular message has
    been received on A.  Suppose that host A receives message
    "<1234@ucbvax.Berkeley.edu>", and wishes to transmit the message to
    host B.

「このメッセージが1人のホスト(Aを言う)が(B) ホストAがメッセージ "<1234@ucbvax.Berkeley.edu を受け取るという特定のメッセージがA.Supposeで受信されていると別のホストに言うことができるihave/sendmeプロトコルの一部である、gt;、」 ホストBにメッセージを送るという願望。

    A sends the control message "ihave <1234@ucbvax.Berkeley.edu> A" to
    host B (by posting it to newsgroup to.B).  B responds with the
    control message "sendme <1234@ucbvax.Berkeley.edu> B" (on newsgroup
    to.A), if it has not already received the message.  Upon receiving

Aがコントロールメッセージを送る、「 ihave <1234@ucbvax.Berkeley.edu 、gt;、ホストB(ニュースグループto.Bにそれを掲示するのによる)へのA」。 Bがコントロールメッセージで応じる、「 sendme <1234@ucbvax.Berkeley.edu 、gt;、既にメッセージを受け取っていないならB」(ニュースグループto.Aの)。 受信に関して

Horton & Adams                                                 [Page 12]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[12ページ]RFC1036規格

    the sendme message, A sends the message to B.

sendmeメッセージ、AはメッセージをBに送ります。

    This protocol can be used to cut down on redundant traffic between
    hosts.  It is optional and should be used only if the particular
    situation makes it worthwhile.  Frequently, the outcome is that,
    since most original messages are short, and since there is a high
    overhead to start sending a new message with UUCP, it costs as much
    to send the ihave as it would cost to send the message itself.

ホストの間の余分な交通のときにこのプロトコルをカットに使用できます。 特定の状況で価値があるようになる場合にだけ、それは、任意であり、使用されるべきです。 頻繁に、結果はほとんどのオリジナルのメッセージが短く、UUCPから新しいメッセージを送り始めるために高いオーバーヘッドがあるのでihaveを送るのにメッセージ自体を送るかかるだろうというのと同じくらい多く費用がかかるということです。

    One possible solution to this overhead problem is to batch requests.
    Several Message-ID's may be announced or requested in one message.
    If no Message-ID's are listed in the control message, the body of
    the message should be scanned for Message-ID's, one per line.

バッチ要求にはこの頭上の問題の1つの可能な解決があります。 IDのいくつかのMessage-ものが、1つのメッセージで発表されるか、または要求されているかもしれません。 IDのMessage-ものが全くコントロールメッセージに記載されないなら、メッセージ欄はIDのMessage-もの(1線あたり1つ)にスキャンされるべきです。

3.3.  Newgroup

3.3. Newgroup

                      newgroup <groupname> [moderated]

newgroup<groupname>。[加減されます]

    This control message creates a new newsgroup with the given name.
    Since no messages may be posted or forwarded until a newsgroup is
    created, this message is required before a newsgroup can be used.
    The body of the message is expected to be a short paragraph
    describing the intended use of the newsgroup.

このコントロールメッセージは名で新しいニュースグループを創設します。 ニュースグループが創設されるまで、メッセージを全く掲示しませんし、また転送しないかもしれないので、ニュースグループを使用できる前に、このメッセージが必要です。 メッセージ欄はニュースグループの意図している使用について説明する短いパラグラフであると予想されます。

    If the second argument is present and it is the keyword moderated,
    the group should be created moderated instead of the default of
    unmoderated.  The newgroup message should be ignored unless there is
    an "Approved" line in the same message header.

2番目の議論が存在していて、それが加減されたキーワードであるなら、グループは非加減されることのデフォルトの代わりに加減されていた状態で創設されるべきです。 「承認された」線が同じメッセージヘッダーにない場合、newgroupメッセージは無視されるべきです。

3.4.  Rmgroup

3.4. Rmgroup

                            rmgroup <groupname>

rmgroup<groupname>。

    This message removes a newsgroup with the given name.  Since the
    newsgroup is removed from every host on the network, this command
    should be used carefully by a responsible administrator.  The
    rmgroup message should be ignored unless there is an "Approved:"
    line in the same message header.

このメッセージは名がいるニュースグループを取り除きます。 ネットワークのすべてのホストからニュースグループを取り除くので、このコマンドは責任がある管理者によって慎重に使用されるべきです。 「承認されたこと」がない場合、rmgroupメッセージは無視されるべきです。 同じメッセージヘッダーに立ち並んでください。

Horton & Adams                                                 [Page 13]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[13ページ]RFC1036規格

3.5.  Sendsys
                           sendsys (no arguments)

3.5. Sendsys sendsys(議論がありません)

    The sys file, listing all neighbors and the newsgroups to be sent to
    each neighbor, will be mailed to the author of the control message
    ("Reply-To", if present, otherwise "From").  This information is
    considered public information, and it is a requirement of membership
    in USENET that this information be provided on request, either
    automatically in response to this control message, or manually, by
    mailing the requested information to the author of the message.
    This information is used to keep the map of USENET up to date, and
    to determine where netnews is sent.

各隣人に送られるすべての隣人とニュースグループを記載して、コントロールメッセージの作者にsysファイルを郵送する、(そうでなければ、プレゼント、“From"であるなら「答える」、) この情報は公開情報であると考えられます、そして、それは手動で自動的にこのコントロールメッセージに対応してこの情報に要求を提供するというUSENETの会員資格の要件です、メッセージの作者に求められた情報を郵送することによって。 この情報は、USENETの地図が時代について行かせて、ネットニュースがどこに送られるかを決定するのに使用されます。

    The format of the file mailed back to the author should be the same
    as that of the sys file.  This format has one line per neighboring
    host (plus one line for the local host), containing four colon
    separated fields.  The first field has the host name of the
    neighbor, the second field has a newsgroup pattern describing the
    newsgroups sent to the neighbor.  The third and fourth fields are
    not defined by this standard.  The sys file is not the same as the
    UUCP L.sys file.  A sample response is:

作者に郵送して戻されたファイルの形式はsysファイルのものと同じであるべきです。 この形式には、4つのコロンの切り離された分野を含んでいて、隣接しているホスト(ローカル・ホストのためのプラス1線)あたり1つの線があります。 最初の分野には、隣人のホスト名があって、2番目の分野に隣人に送られたニュースグループについて説明するニュースグループパターンがあります。 3番目と4番目の分野はこの規格によって定義されません。 sysファイルはUUCP L.sysファイルと同じではありません。 サンプル応答は以下の通りです。

      From: cbosgd!mark  (Mark Horton)
      Date: Sun, 27 Mar 83 20:39:37 -0500
      Subject: response to your sendsys request
      To: mark@cbosgd.ATT.COM

From: cbosgd!マーク(マークホートン)日付: Sun、1983年3月27日の20:39:37 -0500Subject: あなたのsendsys要求To:への応答 mark@cbosgd.ATT.COM

      Responding-System: cbosgd.ATT.COM
      cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to,
            test
      ucbvax:world,comp,to.ucbvax:L:
      cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews
            /cbosg
      cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
      sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews
            /sescent
      npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
      mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi

応じているシステム: cbosgd.ATT.COM cbosgd: osg、cb、btl、ベル、世界、コンピュータ、sci、rec、話、雑ネタ、ニュース、soc、テストucbvax: to.ucbvax: 世界、コンピュータ、L: cbosg: 世界、コンピュータ、ベル、btl、cb、osg、to.cbosg: to.sescent: to.npois: F:/usr/spool/outnews /cbosg cbosgb:osg、to.cbosgb: F:/usr/spool/outnews/cbosgb sescent:世界、コンピュータ、ベル、btl、cb、F:/usr/spool/outnews /sescent npois:世界、コンピュータ、ベル、btl、ug、F:/usr/spool/outnews/npois mhuxi:世界、コンピュータ、ベル、btl、ug、to.mhuxi:F:/usr/spool/outnews/mhuxi

3.6.  Version

3.6. バージョン

                           version (no arguments)

バージョン(議論がありません)

    The name and version of the software running on the local system is
    to be mailed back to the author of the message ("Reply-to" if
    present, otherwise "From").

ローカルシステムにおけるソフトウェア走りの名前とバージョンがメッセージの作者に郵送して戻ることである、(そうでなければ、プレゼント、“From"であるなら「答える」、)

3.7.  Checkgroups

3.7. Checkgroups

Horton & Adams                                                 [Page 14]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[14ページ]RFC1036規格

    The message body is a list of "official" newsgroups and their
    description, one group per line.  They are compared against the list
    of active newsgroups on the current host.  The names of any obsolete
    or new newsgroups are mailed to the user "usenet" and descriptions
    of the new newsgroups are added to the help file used when posting
    news.

1線あたりメッセージ本体は「公式」のニュースグループと彼らの記述のリスト、1つのグループです。 それらは現在のホストで活動的なニュースグループのリストに対して比較されます。 どんな時代遅れの、または、新しいニュースグループの名前もユーザ"usenet"に郵送します、そして、ニュースを掲示するとき使用されるヘルプファイルに新しいニュースグループの記述を追加します。

4.  Transmission Methods

4. 透過法

    USENET is not a physical network, but rather a logical network
    resting on top of several existing physical networks.  These
    networks include, but are not limited to, UUCP, the Internet, an
    Ethernet, the BLICN network, an NSC Hyperchannel, and a BERKNET.
    What is important is that two neighboring systems on USENET have
    some method to get a new message, in the format listed here, from
    one system to the other, and once on the receiving system, processed
    by the netnews software on that system.  (On UNIX systems, this
    usually means the rnews program being run with the message on the
    standard input. <1>)

USENETは物理ネットワークではなく、むしろいくつかの既存の物理ネットワークの上で休息する論理的なネットワークです。 これらのネットワークが含んでいる、有限でなくて、UUCPと、インターネットと、イーサネットと、BLICNネットワークと、NSC Hyperchannelと、BERKNETです。 重要なことはUSENETの上の2台の隣接しているシステムにはネットニュースソフトウェアでそのシステムに新しいメッセージをここに1台のシステムからもう片方まで記載された書式と、受電方式の上の一度処理させる何らかの方法があるということです。 (UNIXシステムの上では、通常、これは標準の入力に関するメッセージがあるrnewsプログラム存在走行を意味します。 <1>。)

    It is not a requirement that USENET hosts have mail systems capable
    of understanding the Internet mail syntax, but it is strongly
    recommended.  Since "From", "Reply-To", and "Sender" lines use the
    Internet syntax, replies will be difficult or impossible without an
    Internet mailer.  A host without an Internet mailer can attempt to
    use the "Path" header line for replies, but this field is not
    guaranteed to be a working path for replies.  In any event, any host
    generating or forwarding news messages must have an Internet address
    that allows them to receive mail from hosts with Internet mailers,
    and they must include their Internet address on their From line.

USENETホストがメールシステムをインターネット・メール構文を理解できるようにするという要件ではありませんが、それは強く推薦されます。 」 「送付者」線使用に答えてください。“From"以来「インターネット構文、回答は、インターネット郵送者なしで難しいか、または不可能になるでしょう。 インターネット郵送者のないホストは、回答に「経路」ヘッダー線を使用するのを試みることができますが、この分野は、回答のための働く経路になるように保証されません。 とにかく、ニュースメッセージを発生するか、または転送するどんなホストも彼らがインターネット郵送者と共にホストからメールを受け取ることができるインターネット・アドレスを持たなければなりません、そして、彼らは彼らのFrom線に関する自分達のインターネット・アドレスを含まなければなりません。

4.1.  Remote Execution

4.1. リモート実行

    Some networks permit direct remote command execution.  On these
    networks, news may be forwarded by spooling the rnews command with
    the message on the standard input.  For example, if the remote
    system is called remote, news would be sent over a UUCP link
    with the command:

ダイレクトリモートコマンド実行を可能にするネットワークもあります。 これらのネットワークでは、標準の入力に関するメッセージでrnewsコマンドをスプールすることによって、ニュースを転送するかもしれません。 例えば、リモートシステムをリモートであると呼ぶなら、コマンドとのUUCPリンクの上にニュースを送るでしょう:

                              uux - remote!rnews

uux--リモートで!、rnews

    and on a Berknet:

そして、Berknetに関して:

                              net -mremote rnews

ネットの-mremote rnews

Horton & Adams                                                 [Page 15]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[15ページ]RFC1036規格

    It is important that the message be sent via a reliable mechanism,
    normally involving the possibility of spooling, rather than direct
    real-time remote execution.  This is because, if the remote system
    is down, a direct execution command will fail, and the message will
    never be delivered.  If the message is spooled, it will eventually
    be delivered when both systems are up.

信頼できるメカニズムでメッセージを送るのは重要です、通常、リアルタイムのリモート実行を指示するよりむしろスプールする可能性にかかわって。 これはリモートシステムがダウンしていると、ダイレクト実行命令が失敗して、メッセージを決して送らないからです。 両方のシステムが結局上がっているとき、メッセージをスプールすると、それを届けるでしょう。

4.2.  Transfer by Mail

4.2. メールで、移してください。

    On some systems, direct remote spooled execution is not possible.
    However, most systems support electronic mail, and a news message
    can be sent as mail.  One approach is to send a mail message which
    is identical to the news message: the mail headers are the news
    headers, and the mail body is the news body.  By convention, this
    mail is sent to the user newsmail on the remote machine.

いくつかのシステムの上では、ダイレクトリモートスプールさせられた実行は可能ではありません。 しかしながら、ほとんどのシステムが電子メールを支持します、そして、メールとしてニュースメッセージを送ることができます。 1つのアプローチはニュースメッセージと同じメール・メッセージを送ることです: メールヘッダはニュースヘッダーです、そして、メール本文はニュース本体です。 コンベンションによって、このメールはリモートマシンの上のユーザnewsmailに送られます。

    One problem with this method is that it may not be possible to
    convince the mail system that the "From" line of the message is
    valid, since the mail message was generated by a program on a
    system different from the source of the news message.  Another
    problem is that error messages caused by the mail transmission
    would be sent to the originator of the news message, who has no
    control over news transmission between two cooperating hosts
    and does not know whom to contact.  Transmission error messages
    should be directed to a responsible contact person on the
    sending machine.

この方法に関する1つの問題はメッセージの“From"線が有効であるとメールシステムに納得させるのが可能でないかもしれないということです、メール・メッセージがニュースメッセージの源と異なったシステムの上のプログラムで発生したので。 別の問題はメール送信で引き起こされたエラーメッセージをニュースメッセージの創始者に送るだろうということです。(その創始者は、2人の協力関係を持っているホストの間のニュース放送を管理しないで、まただれに連絡するかを知りません)。 伝送エラーメッセージは送付マシンの上に責任がある連絡窓口に向けられるべきです。

    A solution to this problem is to encapsulate the news message into a
    mail message, such that the entire message (headers and body) are
    part of the body of the mail message.  The convention here is that
    such mail is sent to user rnews on the remote system.  A mail
    message body is generated by prepending the letter N to each line of
    the news message, and then attaching whatever mail headers are
    convenient to generate.  The N's are attached to prevent any special
    lines in the news message from interfering with mail transmission,
    and to prevent any extra lines inserted by the mailer (headers,
    blank lines, etc.) from becoming part of the news message.  A
    program on the receiving machine receives mail to rnews, extracting
    the message itself and invoking the rnews program.  An example in
    this format might look like this:

この問題の解決はニュースメッセージをメール・メッセージに要約することです、全体のメッセージ(ヘッダーとボディー)がメール・メッセージの身体の一部であるように。 ここのコンベンションはリモートシステムの上でそのようなメールをユーザrnewsに送るということです。 メール・メッセージ本体は、ニュースメッセージの各線への文字Nをprependingして、次に、どんな発生するのに便利なメールヘッダも付けることによって、発生します。 Nのものは、ニュースメッセージのどんな特別な線もメール送信を妨げるのを防いで、郵送者(ヘッダー、空白行など)によって挿入されたどんな余分な線もニュースメッセージの一部になるのを防ぐために付けられています。 メッセージ自体を抜粋して、rnewsプログラムを呼び出して、受信マシンの上のプログラムはメールをrnewsに受け取ります。 この形式の例はこれに似るかもしれません:

Horton & Adams                                                 [Page 16]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[16ページ]RFC1036規格

                Date: Mon, 3 Jan 83 08:33:47 MST
                From: news@cbosgd.ATT.COM
                Subject: network news message
                To: rnews@npois.ATT.COM

日付: 月曜日、1983年1月3日の山地標準時8時33分47秒From: news@cbosgd.ATT.COM Subject: ネットニュースメッセージTo: rnews@npois.ATT.COM

                NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
                NFrom: derek@sask.UUCP (Derek Andrew)
                NNewsgroups: misc.test
                NSubject: necessary test
                NMessage-ID: <176@sask.UUCP>
                NDate: Mon, 3 Jan 83 00:59:15 MST
                N
                NThis really is a test.  If anyone out there more than 6
                Nhops away would kindly confirm this note I would
                Nappreciate it.  We suspect that our news postings
                Nare not getting out into the world.
                N

NPath: cbosgd!mhuxj!harpo!utah-Cs!sask!derek NFrom: derek@sask.UUCP (デリック・アンドリュー)NNewsgroups: ミスクテストNSubject: 必要なテストNMessage-ID: <176@sask.UUCP>NDate: 月曜日に、1983年1月3日の山地標準時0時59分15秒に、N NThisは本当にテストです。 遠くの6Nhopsがむこうのだれであるならも親切に私が確認するこの注意を確認するだろう、Nappreciate、それ。 私たちはそれを疑います。世界に出るのではなく、私たちのニュース任命ナーレ。 N

    Using mail solves the spooling problem, since mail must always be
    spooled if the destination host is down.  However, it adds more
    overhead to the transmission process (to encapsulate and extract the
    message) and makes it harder for software to give different
    priorities to news and mail.

メールを使用すると、スプール問題は、あて先ホストが下がっているならいつもメールをスプールしなければならないので、解決されます。 しかしながら、それで、トランスミッションの過程(メッセージを要約して、抜粋する)により多くのオーバーヘッドを追加して、ソフトウェアがニュースとメールを異なったプライオリティであることが、より困難になります。

4.3.  Batching

4.3. バッチング

    Since news messages are usually short, and since a large number of
    messages are often sent between two hosts in a day, it may make
    sense to batch news messages.  Several messages can be combined into
    one large message, using conventions agreed upon in advance by the
    two hosts.  One such batching scheme is described here; its use is
    highly recommended.

通常、ニュースメッセージが短く、しばしば1日で2人のホストの間に多くのメッセージを送るので、それはバッチニュースメッセージに理解できるかもしれません。 あらかじめ2人のホストによって同意されたコンベンションを使用して、1つの大きいメッセージにいくつかのメッセージを結合できます。 そのような計画のバッチング1つはここで説明されます。 使用は非常にお勧めです。

    News messages are combined into a script, separated by a header of
    the form:

ニュースメッセージは形式のヘッダーによって切り離されたスクリプトに結合されます:

                   #! rnews 1234

#! rnews1234

    where 1234 is the length of the message in bytes.  Each such line is
    followed by a message containing the given number of bytes.  (The
    newline at the end of each line of the message is counted as one
    byte, for purposes of this count, even if it is stored as <CARRIAGE
    RETURN><LINE FEED>.)  For example, a batch of message might look
    like this:

1234がバイトで表現されるメッセージの長さであるところ。 与えられたバイト数を含むメッセージはそのような各線のあとに続いています。 (メッセージのそれぞれの行の終わりのニューラインは1バイトにみなされます、このカウントの目的のために、それが<CARRIAGE RETURN><LINE FEED>として格納されても。) 例えば、メッセージのバッチはこれに似るかもしれません:

Horton & Adams                                                 [Page 17]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[17ページ]RFC1036規格

                #! rnews 239
                From: jerry@eagle.ATT.COM (Jerry Schwarz)
                Path: cbosgd!mhuxj!mhuxt!eagle!jerry
                Newsgroups: news.announce
                Subject: Usenet Etiquette -- Please Read
                Message-ID: <642@eagle.ATT.COM>
                Date: Fri, 19 Nov 82 16:14:55 EST
                Approved: mark@cbosgd.ATT.COM

#! rnews239From: jerry@eagle.ATT.COM (ジェリー・シュワーツ)経路: cbosgd!mhuxj!mhuxt!ワシ!jerryニュースグループ: news.announce Subject: Usenetエチケット--Message IDを読んでください: <642@eagle.ATT.COM>日付: 金曜日、1982年11月19日の東部標準時16時14分55秒に承認されています: mark@cbosgd.ATT.COM

                Here is an important message about USENET Etiquette.
                #! rnews 234
                From: jerry@eagle.ATT.COM (Jerry Schwarz)
                Path: cbosgd!mhuxj!mhuxt!eagle!jerry
                Newsgroups: news.announce
                Subject: Notes on Etiquette message
                Message-ID: <643@eagle.ATT.COM>
                Date: Fri, 19 Nov 82 17:24:12 EST
                Approved: mark@cbosgd.ATT.COM

ここに、USENET Etiquetteに関する重要なメッセージがあります。 #! rnews234From: jerry@eagle.ATT.COM (ジェリー・シュワーツ)経路: cbosgd!mhuxj!mhuxt!ワシ!jerryニュースグループ: news.announce Subject: EtiquetteメッセージMessage-IDに関する注: <643@eagle.ATT.COM>日付: 金曜日、1982年11月19日の東部標準時17時24分12秒に承認されています: mark@cbosgd.ATT.COM

                There was something I forgot to mention in the last
                message.

最後のメッセージで言及する私が、忘れたことがありました。

    Batched news is recognized because the first character in the
    message is #.  The message is then passed to the unbatcher for
    interpretation.

Batchedニュースはメッセージにおける最初のキャラクタがそうので認識されて、次に、#メッセージが解釈のために「非-バッチャー」に通過されるということです。

    The second argument (in this example rnews) determines which
    batching scheme is being used.  Cooperating hosts may use whatever
    scheme is appropriate for them.

2番目の主張(この例のrnewsの)は、どのバッチング計画が使用されているかを決定します。 彼らにとって、何が計画されてもホストが使用するかもしれない協力は適切です。

5.  The News Propagation Algorithm

5. ニュース伝播アルゴリズム

    This section describes the overall scheme of USENET and the
    algorithm followed by hosts in propagating news to the entire
    logical network.  Since all hosts are affected by incorrectly
    formatted messages and by propagation errors, it is important
    for the method to be standardized.

このセクションはUSENETの総合的な計画と伝播ニュースでホストによって従われたアルゴリズムを全体の論理的なネットワークに説明します。 すべてのホストが不当にフォーマットされたメッセージと伝播誤りで影響を受けるので、標準化されるべき方法に、それは重要です。

    USENET is a directed graph.  Each node in the graph is a host
    computer, and each arc in the graph is a transmission path from
    one host to another host.  Each arc is labeled with a newsgroup
    pattern, specifying which newsgroup classes are forwarded along
    that link.  Most arcs are bidirectional, that is, if host A
    sends a class of newsgroups to host B, then host B usually sends
    the same class of newsgroups to host A.  This bidirectionality
    is not, however, required.

USENETは有向グラフです。 グラフによる各ノードはホストコンピュータです、そして、1人のホストから別のホストまでグラフによる各アークはトランスミッション経路です。 どのニュースグループのクラスがそのリンクに沿って進められるかを指定して、各アークはニュースグループパターンでラベルされます。 ほとんどのアークが双方向である、しかしながら、すなわち、ホストAがニュースグループのクラスをホストBに送るなら、通常、BがホストA.Thisに、双方向性なニュースグループの同じクラスを送るホストは必要ではありません。

    USENET is made up of many subnetworks.  Each subnet has a name, such

USENETは多くのサブネットワークで作られます。 各サブネットはaを名義で、あれほどします。

Horton & Adams                                                 [Page 18]

RFC 1036              Standard for USENET Messages         December 1987

USENETメッセージ1987年12月のホートンとアダムス[18ページ]RFC1036規格

    as comp or btl.  Each subnet is a connected graph, that is, a path
    exists from every node to every other node in the subnet.  In
    addition, the entire graph is (theoretically) connected.  (In
    practice, some political considerations have caused some hosts to be
    unable to post messages reaching the rest of the network.)

コンピュータかbtlとして。 各サブネットが接続グラフである、すなわち、経路はサブネットであらゆるノードから他のあらゆるノードまで存在しています。 さらに、全体のグラフは(理論的に)接続されます。 (実際には、いくつかの政治上の問題が、何人かのホストがネットワークの残りに達しながらメッセージを投稿できないことを引き起こしました。)

    A message is posted on one machine to a list of newsgroups. That
    machine accepts it locally, then forwards it to all its neighbors
    that are interested in at least one of the newsgroups of the
    message.  (Site A deems host B to be "interested" in a newsgroup if
    the newsgroup matches the pattern on the arc from A to B.  This
    pattern is stored in a file on the A machine.)  The hosts receiving
    the incoming message examine it to make sure they really want the
    message, accept it locally, and then in turn forward the message to
    all their interested neighbors.  This process continues until the
    entire network has seen the message.

メッセージは1台のマシンの上にニュースグループのリストに掲示されます。 そのマシンは、局所的にそれを受け入れて、次に、少なくともメッセージのニュースグループの1つに興味を持っているすべての隣人にそれを送ります。 (ニュースグループがAからB.Thisパターンまでのアークに関するパターンに合っているなら、Aがニュースグループに「関心がある」ためにホストBであると考えるサイトはAマシンのファイルに格納されます。) 入力メッセージを受け取るホストは、彼らが本当にメッセージが欲しく、局所的にそれを受け入れて、次に、順番にすべての関心がある隣人にメッセージを転送するのを確実にするためにそれを調べます。 全体のネットワークがメッセージを見るまで、この過程は持続します。

    An important part of the algorithm is the prevention of loops.  The
    above process would cause a message to loop along a cycle forever.
    In particular, when host A sends a message to host B, host B will
    send it back to host A, which will send it to host B, and so on.
    One solution to this is the history mechanism.  Each host keeps
    track of all messages it has seen (by their Message-ID) and
    whenever a message comes in that it has already seen, the incoming
    message is discarded immediately.  This solution is sufficient to
    prevent loops, but additional optimizations can be made to avoid
    sending messages to hosts that will simply throw them away.

アルゴリズムの重要な部分は輪の防止です。 上の過程はいつまでも1サイクルに沿って輪にするメッセージを引き起こすでしょう。ホストAがホストBにメッセージを送るとき、特に、ホストBはホストAなどにそれを送り返すでしょう。(そのホストは、ホストBにそれを送るでしょう)。 この1つの解決策が歴史メカニズムです。 各ホストはそれが見た(それらのMessage-IDのそばで)すべてのメッセージの動向をおさえます、そして、メッセージが既に見たので来るときはいつも、入力メッセージはすぐに、捨てられます。 単に彼らを捨てるホストにメッセージを送るのを避けるのを追加最適化をこの解決策が輪を防ぐことができるくらいすることができます。

    One optimization is that a message should never be sent to a machine
    listed in the "Path" line of the header.  When a machine name is
    in the "Path" line, the message is known to have passed through the
    machine.  Another optimization is that, if the message originated
    on host A, then host A has already seen the message.  Thus, if a
    message is posted to newsgroup misc.misc, it will match the pattern
    misc.all (where all is a metasymbol that matches any string), and
    will be forwarded to all hosts that subscribe to misc.all (as
    determined by what their neighbors send them).  These hosts make up
    the misc subnetwork.  A message posted to btl.general will reach all
    hosts receiving btl.all, but will not reach hosts that do not get
    btl.all.  In effect, the messages reaches the btl subnetwork.  A
    messages posted to newsgroups misc.misc,btl.general will reach all
    hosts subscribing to either of the two classes.

1つの最適化はヘッダーの「経路」線で記載されたマシンにメッセージを決して送るべきでないということです。 「経路」線にマシン名があるとき、メッセージがマシンを通り抜けたのが知られています。 別の最適化は次に、メッセージがホストAの上で由来したならホストAが既にメッセージを見たということです。 したがって、メッセージがニュースグループミスク雑ネタに掲示されると、パターンミスクを合わせる、すべて(すべてがどんなストリングにも合っているmetasymbolであるところ)、ミスクにすべて(彼らの隣人が彼らを送ることで同じくらい断固とする)で加入するすべてのホストに送るでしょう。 これらのホストは雑ネタのサブネットワークを作ります。 メッセージは、btl.allを受け取るすべてのホストをbtl.general will範囲に掲示しますが、btl.allを手に入れないホストに届かないでしょう。 事実上、メッセージはbtlサブネットワークに達します。 メッセージは2つのクラスのどちらかに加入するすべてのホストをニュースグループミスク雑ネタ、btl.general will範囲に掲示しました。

Notes

注意

    <1>  UNIX is a registered trademark of AT&T.

<の1>のUNIXはAT&Tの登録商標です。

Horton & Adams                                                 [Page 19]

ホートンとアダムス[19ページ]