RFC850 日本語訳

RFC 850                                         June 1983

RFC850 1983年6月

       Standard for Interchange of USENET Messages

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

                      Mark R. Horton

マークR.ホートン

[ This memo is distributed as an RFC  only  to  make  this
information  easily  accessible to researchers in the ARPA
community.  It does not specify  an  Internet  standard. ]

[ このメモはRFCとして配布されますが、ARPA共同体でこの情報を研究者には容易にアクセスしやすくします。 それはインターネット標準を指定しません。 ]

1.  Introduction

1. 序論

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

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

There are five sections to  this  document.   Section  two
section  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.  Article Format

2. 記事形式

The primary consideration in choosing an article format is
that  it  fit  in with existing tools as well as possible.
Existing tools include both implementations  of  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
ARPANET, and this  format  meets  most  of  the  needs  of
USENET.    Since   the   ARPANET   format  is  extensible,
extensions to meet the  additional  needs  of  USENET  are
easily  made  within the ARPANET standard.  Therefore, the
rule is adopted that all  USENET  news  articles  must  be
formatted as valid ARPANET mail messages, according to the
ARPANET  standard  RFC  822.   This   standard   is   more
restrictive  than the ARPANET standard, placing additional
requirements on each article and forbidding use of certain
ARPANET  features.   However, it should always be possible
to use a tool expecting an ARPANET message  to  process  a
news  article.   In  any  situation  where  this  standard
conflicts with the ARPANET standard,  RFC  822  should  be
considered correct and this standard in error.

記事形式を選ぶことにおける第一の考慮は既存のツールとできるだけよく合ったということです。 既存のツールはメールの実現とニュースの両方を含んでいます。 (イリノイ大学からのnotesfilesシステムはニュース実現であると考えられます。) メール・メッセージのための標準書式はアルパネットの何年間も存在しています、そして、この形式はUSENETの需要の大部分を満たします。 アルパネット形式が広げることができるので、アルパネット規格の中で容易にUSENETの追加需要を満たす拡大をします。 したがって、有効なアルパネットメール・メッセージとしてすべてのUSENETニュース記事をフォーマットしなければならないという規則は採用されます、アルパネット標準のRFC822によると。 この規格はアルパネット規格より制限しています、あるアルパネット機能の各記事と険しい使用に関する追加要件を置いて。 しかしながら、ニュース記事を処理するアルパネットメッセージを予想するツールを使用するのはいつも可能であるべきです。 この規格がアルパネット規格と衝突して、RFC822が正しいと考えられるべきであるどんな状況と間違いこの規格でも。

                          - 1 -


- 1 -

An example message is included to illustrate the fields.

例のメッセージは、分野を例証するために含まれています。

     Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
     Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
     Path: cbosgd!mhuxj!mhuxt!eagle!jerry
     From: jerry@eagle.uucp (Jerry Schwarz)
     Newsgroups: net.general
     Subject: Usenet Etiquette -- Please Read
     Message-ID: <642@eagle.UUCP>
     Date: Friday, 19-Nov-82 16:14:55 EST
     Followup-To: net.news
     Expires: Saturday, 1-Jan-83 00:00:00 EST
     Date-Received: Friday, 19-Nov-82 16:59:30 EST
     Organization: Bell Labs, Murray Hill

リレーバージョン: バージョンB 2.10 2/13/83。 サイトcbosgd.UUCP Posting-バージョン: バージョンB 2.10 2/13/83。 サイトeagle.UUCP Path: cbosgd!mhuxj!mhuxt!ワシ!jerry From: jerry@eagle.uucp (ジェリー・シュワーツ)ニュースグループ: net.general Subject: Usenetエチケット--Message IDを読んでください: <642@eagle.UUCP>日付: 東部標準時1982年11月19日金曜日16時14分55秒Followup-To: net.news Expires: 東部標準時1983年1月1日土曜日0時0分0秒は日付で受けました: 東部標準時1982年11月19日金曜日16時59分30秒の組織: ベル研究所、マリー・ヒル

     The body of the article 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 articles  in  this  format  to
ease upward conversion.

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

     From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
     Newsgroups: net.general
     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(ジェリー・シュワーツ)ニュースグループ: net.general 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 article comes here, after a blank line.

記事のボディーは空白行の後にここに来ます。

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

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

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

お願いします、Read。Aeagle.642net.general cbosgd!mhuxj!mhuxt!ワシ!jerry1982年11月19日金曜日16時14分55秒Usenet Etiquette--、記事のボディーはここに来ます、空白行なしで。

An article consists of several header lines, followed by a
blank  line,  followed  by  the  body of the message.  The
header lines consist of a keyword, a colon, a  blank,  and
some  additional  information.   This  is  a subset of the
ARPANET 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  ARPANET  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 ARPANET
convention of continuation header lines (beginning with  a
blank or tab) is allowed.

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

                          - 2 -


- 2 -

Certain  headers  are  required,   certain   headers   are
optional.   Any unrecognized headers are allowed, and will
be passed through unchanged.   The  required  headers  are
Relay-Version,  Posting-Version,  From,  Date, Newsgroups,
Subject,  Message-ID,  Path.   The  optional  headers  are
Followup-To,  Date-Received,  Expires,  Reply-To,  Sender,
References, Control, Distribution, Organization.

確信しているヘッダーが必要であり、確信しているヘッダーは任意です。 どんな認識されていないヘッダーも、許容されていて、変わりがない状態で通り抜けるでしょう。 Subject、Message-ID Path、必要なヘッダーはRelay-バージョン、Posting-バージョン、From、Date、ニュースグループです。 任意のヘッダーがそうである、Followup、-、Dateを受け取られていさせる、Expires、Reply、-、Sender、References、Control、Distribution、Organization。

2.1  Required Headers

2.1 必要なヘッダー

2.1.1  Relay-Version  This header line shows  the  version
of  the  program  responsible for the transmission of this
article over the immediate link, that is, the program that
is  relaying the article from the next site.  For example,
suppose site A sends an article to  site  B,  and  site  B
forwards  the  article  to  site  C.   The  message  being
transmitted from A to B would have a Relay-Version  header
identifying  the  program  running  on  A, and the message
transmitted from B to C would identify the program running
on  B.  This header can be used to interpret older headers
in an upward compatible way.  Relay-Version must always be
the  first  in  a message; thus, all articles meeting this
standard will begin with an upper case   "R".    No  other
restrictions are placed on the order of header lines.

2.1.1 リレーバージョンThisヘッダー線は即座のリンク(すなわち、次のサイトからの記事をリレーしているプログラム)の上にこの記事の伝達に原因となるプログラムのバージョンを示しています。 例えば、サイトAがサイトBに記事を送ると仮定してください。そうすれば、サイトBはサイトC.に記事を転送します。Relay-バージョンヘッダーはAからBまで送られるメッセージでAで動くプログラムを特定するでしょう、そして、BからCまで送られたメッセージはB.で動くプログラムを特定するでしょう。上向きのコンパチブル方法で、より年取ったヘッダーを解釈するのにThisヘッダーは使用できます。 いつもリレーバージョンはメッセージで1番目であるに違いありません。 したがって、この規格を満たすすべての記事が大文字「R」で始まるでしょう。 他の制限は全くヘッダー線の注文に関して課されません。

The line contains two  fields,  separated  by  semicolons.
The fields are the version and the full domain name of the
site.  The version should identify the system program used
(e.g.,   "B")   as  well  as  a version number and version
date.  For example, the header line might contain

線はセミコロンによって切り離された2つの野原を含んでいます。 分野は、サイトのバージョンと完全なドメイン名です。 バージョンはバージョン番号とバージョン日付と同様に使用された(例えば、「B」)システムプログラムを特定するべきです。 例えば線が含むかもしれないヘッダー

   Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP

リレーバージョン: バージョンB 2.10 2/13/83。 サイトcbosgd.UUCP

This header should not be passed on to  additional  sites.
A  relay  program,  when  passing  an  article  on, should
include only its own Relay-Version, not the  Relay-Version
of  some other site.  (For upward compatibility with older
software, if a Relay-Version is found in a header which is
not the first line, it should be assumed to be moved by an
older version of news and deleted.)

このヘッダーを追加サイトに渡すべきではありません。 記事を伝えるとき、リレープログラムはある他のサイトのRelay-バージョンではなく、それ自身だけのRelay-バージョンを含んでいるはずです。 (より古いソフトウェアがある上位互換性において、Relay-バージョンが最初の線でないヘッダーで見つけられるなら、ニュースの旧式のバージョンで感動していて、削除されると思われるべきです。)

2.1.2  Posting-Version    This   header   identifies   the
software  responsible  for  entering this message into the
network.  It has the same  format  as  Relay-Version.   It
will  normally  identify  the same site as the Message-ID,
unless the posting site is serving  as  a  gateway  for  a
message  that  already  contains a message ID generated by
mail.  (While it is permissible for a gateway  to  use  an
externally  generated message ID, the message ID should be
checked to ensure it conforms to this standard and to  RFC
822.)

2.1.2 任命バージョンThisヘッダーはこのメッセージをネットワークに入力するのに原因となるソフトウェアを特定します。 それには、Relay-バージョンと同じ形式があります。 通常、それは、同じサイトがMessage-IDであると認識するでしょう、任命サイトが既にIDがメールで発生させたメッセージを含むメッセージのためのゲートウェイとして機能していない場合。 (ゲートウェイが外部的に発生したメッセージIDを使用するのが、許されている間、メッセージIDはそれがこの規格と、そして、RFC822に従うのを保証するためにチェックされるべきです。)

                          - 3 -


- 3 -

2.1.3  From  The From line contains the electronic mailing
address  of  the  person who sent the message, in the ARPA
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 article, unless the Sender
header is present, in which case the From header might not
be  verified.   Note  that  in  all site and domain names,
upper  and  lower  case  are  considered  the  same,  thus
mark@cbosgd.UUCP,  mark@cbosgd.uucp,  and mark@CBosgD.UUcp
are all equivalent.  User names may or  may  not  be  case
sensitive,   for   example,   Billy@cbosgd.UUCP  might  be
different from BillY@cbosgd.UUCP.  Programs  should  avoid
changing  the case of electronic addresses when forwarding
news or mail.

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

RFC 822 specifies that all text in parentheses  is  to  be
interpreted as a comment.  It is common in ARPANET 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 article, or it appears
before an electronic address enclosed in  angle  brackets.
Thus, the three permissible forms are:

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

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

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

Full names may contain any printing ASCII characters  from
space through tilde, with the exceptions that they may not
contain parentheses  "("   or   ")",   or  angle  brackets
"<"   or  ">".    Additional restrictions may be placed on
full names  by  the  mail  standard,  in  particular,  the
characters  comma   ",",  colon  ":",  and semicolon   ";" 
are inadvisable in full names.

または、フルネームがスペースからティルドまでどんな印刷ASCII文字も含むかもしれなくて、それらがそうしない例外で括弧を含んでください、「(「」、)、」 括弧"<"か">"を傾けてください。 「追加制限はフルネームに関してメール規格によって課されるかもしれません、特に、キャラクタコンマ」、」、コロン、」 : 」 セミコロン、」、;、」 完全が命名する勧められないコネはそうですか?

2.1.4  Date  The Date line (formerly   "Posted")   is  the
date,  in  a  format  that  must be acceptable both to the
ARPANET and to the getdate routine, that the  article  was
originally  posted  to  the  network.   This  date remains
unchanged as the  article  is  propagated  throughout  the
network.  One format that is acceptable to both is

2.1.4 Dateが裏打ちする(以前、「掲示される」)日付はアルパネットと、そして、getdateルーチンに許容するに違いない形式の元々記事がそうであったネットワークに掲示された日付です。 記事がネットワーク中で伝播されるのに従って、この日付は変わりがありません。 両方に許容している1つの形式がそうです。

     Weekday, DD-Mon-YY HH:MM:SS TIMEZONE

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

Several examples of  valid  dates  appear  in  the  sample
article above.  Note in particular that ctime format:

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

     Wdy Mon DD HH:MM:SS YYYY

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

                          - 4 -


- 4 -

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

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

The contents of the TIMEZONE field is currently subject to
worldwide time zone  abbreviations,  including  the  usual
American  zones  (PST, PDT, MST, MDT, CST, CDT, EST, EDT),
the   other   North   American   zones   (Bering   through
Newfoundland),  European  zones,  Australian zones, and so
on.  Lacking a complete list at present (and unsure if  an
unambiguous   list   exists),   authors  of  software  are
encouraged to keep this code flexible, and  in  particular
not  to  assume  that  time  zone  names are exactly three
letters long.   Implementations  are  free  to  edit  this
field,  keeping  the  time the same, but changing the time
zone (with an appropriate adjustment  to  the  local  time
shown) to a known time zone.

TIMEZONE分野のコンテンツは現在世界的な時間帯の略語を受けることがあります、普通のアメリカのゾーンを含んでいて(太平洋標準時であって、太平洋夏時間、MST、MDT、CST、米国東部標準時の、そして、東部夏時間のCDT)、他の北米のゾーン(Beringからニューファンドランド)、ヨーロッパのゾーン、オーストラリアのゾーンなど。 現在と(不確か明白なリストが存在するかどうか)で全リストを欠いていて、ソフトウェアの作者がこのコードをフレキシブルに保つよう奨励されて、長い間、ゾーン名は、まさに特に、その時を仮定しないためには、3個の手紙です。 実現は無料でこの分野を編集できます、知られている時間帯に時間を同じに保ちますが、時間帯を変えて(現地時間まで示される適当な調整で)。

2.1.5  Newsgroups  The  Newsgroups  line  specifies  which
newsgroup  or newsgroups the article belongs in.  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.

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

Wildcards (e.g., the word  "all")  are never allowed in  a
Newsgroups  line.  For example, a newsgroup  "net.all"  is
illegal, although a newsgroup name    "net.sport.football" 
is permitted.

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

If an article is received with a Newsgroups  line  listing
some  valid newsgroups and some invalid newsgroups, a site
should  not  remove  invalid  newsgroups  from  the  list.
Instead,  the  invalid  newsgroups should be ignored.  For
example,  suppose  site  A  subscribes  to   the   classes
"btl.all"   and   "net.all",   and exchanges news articles
with site B,  which  subscribes  to   "net.all"   but  not
"btl.all".      Suppose   A   receives   an  article  with
"Newsgroups: net.micro,btl.general".     This  article  is
passed  on  to  B because B receives net.micro, but B does
not receive btl.general.  A must leave the Newsgroup  line
unchanged.   If  it  were  to  remove  "btl.general",  the
edited header could  eventually  reenter  the    "btl.all" 
class,  resulting in an article that is not shown to users
subscribing  to   "btl.general".    Also,  followups  from
outside  "btl.all"  would not be shown to such users.

ニュースグループ線がいくつかの有効なニュースグループといくつかの無効のニュースグループを記載している状態で記事を受け取るなら、サイトはリストから無効のニュースグループを取り除くべきではありません。 代わりに、無効のニュースグループは無視されるべきです。 例えば、サイトAがクラス"btl.all"と"net.all"に加入して、サイトBとニュース記事を交換すると仮定してください。(サイトは"btl.all"ではなく"net.all"に加入します)。 Aが記事を受け取ると仮定してください、「ニュースグループ:」 「net.micro、btl.general。」 Bがnet.microを受けるので、この記事はBに通過されますが、Bはbtl.generalを受けません。 絶対に必要なものはニュースグループ線を変わりがないままにします。 "btl.general"を取り除くなら、編集されたヘッダーは結局"btl.all"のクラスに再入できるでしょうに、"btl.general"に加入するユーザに示されない記事をもたらして。 また、"btl.all"の外からの追跡はそのようなユーザに示されないでしょう。

                          - 5 -


- 5 -

2.1.6  Subject   The  Subject  line  (formerly    "Title")
tells  what the article is about.  It should be suggestive
enough of the contents of the article to enable  a  reader
to  make  a  decision whether to read the article based on
the  subject  alone.   If  the  article  is  submitted  in
response  to another article (e.g., is a  "followup")  the
default subject should  begin  with  the  four  characters
"Re: "   and the References line is required.    (The user
might wish to edit the subject of the  followup,  but  the
default should begin with  "Re: ".)

2.1.6 Subjectが裏打ちする被験者(以前「タイトル」)は、記事が何に関するかを言います。 それは記事のコンテンツが読者が対象に基づく記事を読むかどうかという決定を単独にするのを可能にするほど思わせ振りであるべきです。 デフォルト対象が4つのキャラクタ「Re:」で始めるはずである別の記事(例えば、「追跡」である)に対応して記事を提出するなら 「そして、References線が必要です。」 (ユーザは追跡の対象を編集したがっているかもしれませんが、デフォルトは「Re:」で始まるべきです。)

2.1.7  Message-ID  The Message-ID line gives the article a
unique  identifier.  The same message ID may not be reused
during the lifetime of any article 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

2.1.7 Message-IDが裏打ちするメッセージIDはユニークな識別子を記事に与えます。 同じメッセージIDはどんな記事の生涯も同じメッセージIDで再利用されないかもしれません。 (メッセージIDが全く少なくとも2年間再利用されないのは、お勧めです。) IDのものには構文があるというメッセージ

     "<" "string not containing blank or >" ">"

"<"「空白を含まないストリングか>」">"

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

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

     "<" "unique" "@" "full domain name" ">"

"<"「ユニークである」"@"「完全なドメイン名」">"

where  "full domain name"  is the full name of the host at
which  the article entered the network, including a domain
that host is in, and unique  is  any  string  of  printing
ASCII  characters,  not  including  "<", ">", or "@".  For
example,  the  "unique"   part   could   be   an   integer
representing  a  sequence number for articles submitted to
the network, or a short string derived from the  date  and
time  the article was created.  For example, valid message
ID for an article submitted from  site  ucbvax  in  domain
Berkeley.ARPA   would   be  "<4123@ucbvax.Berkeley.ARPA>".
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,  nor  that  it  is  unique  in  the  first  14
characters.

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

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.   All
characters  between  the  angle  brackets must be printing
ASCII characters.

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

2.1.8  Path  This line shows the path the article 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,      thus

2.1.8 経路This線は、記事が現在のシステムに達するように取ったのを経路に案内します。 システムがメッセージを転送するとき、それはPath線でそれ自身の名前をシステムのリストに追加するべきです。 名前はどんな句読文字やキャラクタによってもこのようにして切り離されるかもしれません。

                          - 6 -


- 6 -

"cbosgd!mhuxj!mhuxt",    "cbosgd,  mhuxj,  mhuxt",     and
"@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp"      and       even
"teklabs,   zehntel,   sri-unix@cca!decvax"    are   valid
entries.  (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
third example was  "teklabs".   Letters,  digits,  periods
and  hyphens  are  considered  part  of  site names; other
punctuation, including blanks, are considered separators.

「」 @mhuxt「cbosgd!mhuxj!mhuxt」、「cbosgd、mhuxj、mhuxt」と@cbosgd.uucp、@mhuxj.uucp、.uucp」と「teklabs、zehntel、 sri-unix@cca!decvax 」さえそうです。有効なエントリー。 (後者の経路はそのオーダーをdecvax、cca、様unix、zehntel、およびteklabsを通り抜けたメッセージを示します。) 追加名前は左から言い足されるべきでした、例えば、大部分は最近、3番目の例の名前が"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
system.

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

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  travelled  to  reach  the  local  site.
There  are  several  uses for this information.  One is to
monitor USENET routing for performance  reasons.   Another
is  to  establish  a path to reach new sites.  Perhaps the
most important is to cut down on redundant USENET  traffic
by failing to forward a message to a site that is known to
have already received it.   In  particular,  when  site  A
sends  an article to site B, the Path line includes   "A",
so that site B will not immediately send the article  back
to  site  A.   The  site  name  each site uses to identify
itself should be  the  same  as  the  name  by  which  its
neighbors  know  it,  in  order  to make this optimization
possible.

Path線を回答に使用しないで、郵送先住所としてみなすべきではありません。 メッセージがローカル・サイトに達するように移動したのをルートに示すのは意図しています。 この情報へのいくつかの用途があります。 1つは性能理由でUSENETルーティングをモニターすることになっています。 別のものは、新しいサイトに達するように経路を確立することになっています。 余分なUSENET交通のカットには恐らく最も重要であるのが、既にそれを受けたのが知られているサイトにメッセージを転送しないことによって、あります。 サイトAがサイトBに記事を送るとき、特に、Path線が「A」を含んでいるので、BがすぐにA. 各サイトがそれ自体を特定するのに使用するサイト名を位置させるように記事を返送しないそのサイトは隣人が知っているそれの名前と同じであるべきです、この最適化を可能にするように。

A site adds its own name to the front of a  path  when  it
receives  a message from another site.  Thus, if a message
with path A!X!Y!Z is passed from site A to site 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  sites  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.   Thus, sites are
required to continue to keep the Path line  in  a  working
reply  format  as much as possible, until January 1, 1984.
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

特別な上位互換性注意: そして、From、Sender、Reply、-、インターネット形式には線があって、多くのUSENETサイトがまだ郵送者をインターネット形式を理解できるようにしていないので、それはPathヘッダーと回答機能との関係を完全に断ち切る回答能力を壊すでしょう。 したがって、サイトが働く回答形式でPath線をできるだけ保ち続けるのに必要です、1984年1月1日まで。 経路が、より古い実現でいつも有効な回答ストリングであるというわけではないと認められて、この問題を修正するという要件は全く実現に置かれません。 しかしながら

                          - 7 -


- 7 -

existing  convention of placing the site name and an   "!" 
at the front of the path, and of starting  the  path  with
the  site  name,  an   "!",   and the user name, should be
maintained at least until 1984.

サイト名と“!"を経路の前にみなして、サイト名から経路を始める既存のコンベンション(“!"、およびユーザ名)は、少なくとも1984年まで維持されるべきです。

2.2  Optional Headers

2.2 任意のヘッダー

2.2.1  Reply-To  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.

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

2.2.2  Sender  This field is present only if the submitter
manually enters a From line.  It is intended to record the
entity responsible  for  submitting  the  article  to  the
network,  and  should  be  verified by the software at the
submitting site.

2.2.2 submitterが手動でFrom線に入る場合にだけ、Thisがさばく送付者は出席しています。 それは、ネットワークに記事を提出するのに原因となる実体を記録することを意図して、提出サイトのソフトウェアによって確かめられるはずです。

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

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

     From: smith@ucbvax.uucp (John Smith)
     Sender: jones@cca.arpa (Sarah Jones)

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

If a gateway  program  enters  a  mail  message  into  the
network at site sri-unix, the lines might read

線が、ゲートウェイプログラムがサイト様unixでメール・メッセージをネットワークに入力すると読むかもしれないなら

     From: John.Doe@CMU-CS-A.ARPA
     Sender: network@sri-unix.ARPA

From: John.Doe@CMU-CS-A.ARPA 送付者: network@sri-unix.ARPA

The primary purpose of this field is to be able  to  track
down  articles 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  This  line  has  the  same  format  as
Newsgroups.   If  present,  follow-up  articles  are to be
posted to the newsgroup(s) listed here.  If this  line  is
not  present,  followups  are  posted  to the newsgroup(s)
listed in the Newsgroups line, except  that  followups  to
"net.general"  should instead go to  "net.followup".

2.2.3、追跡、-、This線には、ニュースグループと同じ形式があります。 現在の、そして、追跡している記事がニュースグループに掲示されることであるなら、(s)はここに記載しました。 この線が存在していないなら、追跡はニュースグループ線で記載されたニュースグループに掲示されます、"net.general"への追跡が代わりに"net.followup"に行くべきであるのを除いて。

2.2.4  Date-Received  This line (formerly  "Received")  is
in  a  legal  USENET date format.  It records the date and
time that the article was  first  received  on  the  local
system.   If  this  line  is  present  in an article being
transmitted from one host to another, the  receiving  host
should  ignore  it  and  replace it with the current date.
Since this field is intended for local use only,  no  site
is  required  to support it.  However, no site should pass
this field on to another site unchanged.

2.2.4 法的なUSENET日付の形式には日付で容認されたThis線(以前、「受信する」)があります。 それは最初にローカルシステムに記事を受け取った日時に記録します。 この線が1人のホストから別のホストまで伝えられながら記事に存在しているなら、受信ホストは、それを無視して、現在の期日に取り替えるべきです。 この分野が地方の使用だけのために意図するので、サイトは全くそれを支持するのに必要ではありません。 しかしながら、どんなサイトもこの野原を別のサイトに変わりがない状態で通り過ぎるべきではありません。

                          - 8 -


- 8 -

2.2.5  Expires  This line,  if  present,  is  in  a  legal
USENET  date  format.  It specifies a suggested expiration
date for the article.  If not present, the  local  default
expiration date is used.

2.2.5、プレゼントが法的なUSENETで形式の日付を入れることであるなら、This線を吐き出します。 それは提案された有効期限を記事に指定します。 プレゼント、地方でないのがデフォルトとするなら、有効期限は使用されています。

This field is intended to be used  to  clean  up  articles
with  a  limited usefulness, or to keep important articles
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 sites have
local  policies  for  expiration  of  news  (depending  on
available disk space, for instance), users are discouraged
from providing expiration dates for articles 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.

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

2.2.6  References  This field lists the  message  ID's  of
any articles prompting the submission of this article.  It
is required for all follow-up articles, and forbidden when
a new subject is raised.  Implementations should provide a
follow-up command, which allows a user to post a follow-up
article.   This  command  should  generate  a Subject line
which is the same as the original article, 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  article (including the angle brackets).
If the original article does have a References  line,  the
followup  article should have a References line containing
the text of the original References line, a blank, and the
message ID of the original article.

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

The purpose of the References header is to allow  articles
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  may not make use of this header, but all
automatically  generated  followups  should  generate  the
References line for the benefit of systems that do use it,
and manually generated followups (e.g. typed in well after
the  original  article  has  been  printed by the machine)
should be encouraged to include them as well.

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

2.2.7  Control  If an article contains a Control line, the
article  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.

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

                          - 9 -


- 9 -

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"に合っているメッセージはコントロールメッセージとして解釈されるべきです。 Controlでないなら: ヘッダーがそのようなメッセージに出席している、対象はコントロールメッセージとして使用されます。 しかしながら、このパターンに合っているニュースグループに関するメッセージはこの規格に従いません。

2.2.8  Distribution   This  line  is  used  to  alter  the
distribution scope of the message.  It has the same format
as 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 instead of the Newsgroups line.  Thus, a car for sale
in New Jersey might have headers including

2.2.8 Thisが裏打ちする分配は、メッセージの分配範囲を変更するのに使用されます。 それには、ニュースグループ線と同じ形式があります。 ニュースグループはまだユーザ購読を制御していますが、ニュースグループ線の代わりにDistribution線の上でニュースグループに加入するすべてのシステムにメッセージを送ります。 したがって、ヘッダーが含んでいて、ニュージャージーの売り物の車はそうしたかもしれません。

     Newsgroups: net.auto,net.wanted
     Distribution: nj.all

ニュースグループ: net.auto、net.wanted Distribution: nj.all

so that  it  would  only  go  to  persons  subscribing  to
net.auto  or  net.wanted within New Jersey.  The intent of
this header is to further restrict the distribution  of  a
newsgroup, not to increase it.  A local newsgroup, such as
nj.crazy-eddie, will probably not be propagated  by  sites
outside  New  Jersey  that do not show such a newsgroup as
valid.  Wildcards in newsgroup names in  the  Distribution
line are allowed.  Followup articles should default to the
same Distribution line as the original  article,  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.

ニュージャージーの中でnet.autoかnet.wantedに加入するために人々のものになるだけであるように。 このヘッダーの意図はそれを増加させるのではなく、さらにニュースグループの分配を制限することです。 nj.crazy-eddieなどの地方のニュースグループはたぶんニュージャージーの外の有効であるようなニュースグループを示さないサイトによって伝播されないでしょう。 ニュースグループ名のDistribution線でのワイルドカードは許容されています。 追跡記事がオリジナルの記事と同じDistribution線をデフォルトとするべきですが、それが元々、制限されて、広くより分配された回答が適切であるなら、ユーザは、それをより限られたものに変えるか、または分配を徐々に拡大することができます。

2.2.9  Organization  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 site names are often cryptic enough to make
it  hard  to  recognize the organization by the electronic
address.

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

3.  Control Messages

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

This section lists the control messages currently defined.
The  body  of  the  Control header 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
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.

このセクションは現在定義されているコントロールメッセージをリストアップします。 Controlヘッダーのボディーはコントロールメッセージです。 メッセージはゼロの系列であるか以上が余白(空白かタブ)によって切り離された単語です。 最初の単語がコントロールメッセージの名前である、残っている単語はメッセージへのパラメタです。 また、ヘッダーとメッセージ欄の残りは潜在的パラメタです。 例えば、From線は郵送される応答がことであるアドレスを示すかもしれません。

                          - 10 -


- 10 -

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

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

3.1  Cancel

3.1は取り消されます。

     cancel <message ID>

<メッセージID>を取り消してください。

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

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

Only the author of the article or the local super user  is
allowed  to  use  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.

記事の作者か地元のスーパーユーザだけがこのメッセージを使用できます。 メッセージの確かめられた送付者はSender線であるかどんなSender線も存在していないなら、Fromが立ち並んでいます。 キャンセルメッセージの確かめられた送付者はSenderかFromがさばくオリジナルのメッセージのどちらかと同じであるに違いありません。 キャンセルメッセージの確かめられた送付者はオリジナルのメッセージでunverified Fromに合うことができます。

3.2  Ihave/Sendme

3.2 Ihave/Sendme

     ihave <message ID list> <remotesys>
     sendme <message ID list> <remotesys>

ihave<メッセージIDリスト><remotesys>sendme<メッセージIDリスト><remotesys>。

This message is part  of  the   "ihave/sendme"   protocol,
which  allows  one  site  (say  "A")  to tell another site
("B")  that  a particular message has been received on  A.
Suppose  that site A receives article  "ucbvax.1234",  and
wishes to transmit the article to site  B.   A  sends  the
control  message   "ihave  ucbvax.1234  A"   to site B (by
posting it to newsgroup  "to.B").   B  responds  with  the
control  message   "sendme  ucbvax.1234  B"  (on newsgroup
to.A) if it has not already received  the  article.   Upon
receiving the Sendme message, A sends the article to B.

このメッセージは"ihave/sendme"プロトコルの一部です。(あるサイト(「A」を言う)が、それでそのサイトAが「0.1234インチ、およびサイトB(ニュースグループ"to.B"にそれを掲示するのによる)にAが"ihave ucbvax.1234 A"というコントロールメッセージを送るB.を位置させるように記事を伝えるという願望をucbvaxする」という記事を受け取るなら特定のメッセージがA.に受け取られたと別のサイト(「B」)に言うことができます)。 既に記事を受け取っていないなら、Bはコントロールメッセージ"sendme ucbvax.1234 B"(ニュースグループto.Aの)と共に応じます。 Sendmeメッセージを受け取ると、Aは記事をBに送ります。

This protocol can be used to cut down on redundant traffic
between  sites.  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 article 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のものが1つのメッセージで発表されるか、または要求されているかもしれないといういくつかのメッセージ。 メッセージでないなら、IDのものはコントロールメッセージに記載されて、メッセージ欄はメッセージのために1つ歳のIDの1線あたりのものにスキャンされるべきです。

                          - 11 -


- 11 -

3.3  Newgroup

3.3 Newgroup

     newgroup <groupname>

newgroup<groupname>。

This control message creates a new newsgroup with the name
given.  Since no articles 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.

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

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 site on the
network, this  command  should  be  used  carefully  by  a
responsible administrator.

このメッセージは名がいるニュースグループを取り除きます。 ネットワークに関するあらゆるサイトからニュースグループを取り除くので、このコマンドは責任がある管理者によって慎重に使用されるべきです。

3.5  Sendsys

3.5 Sendsys

     sendsys (no arguments)

sendsys(議論がありません)

The   "sys"   file,  listing  all  neighbors   and   which
newsgroups  are  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 site (plus one  line  for  the  local
site),  containing four colon separated fields.  The first
field has the site 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.  A sample response:

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

     From cbosgd!mark  Sun Mar 27 20:39:37 1983
     Subject: response to your sendsys request
     To: mark@cbosgd.UUCP

cbosgd!から、1983年3月27日日曜日20時39分37秒がSubject:であるとマークしてください。 あなたのsendsys要求To:への応答 mark@cbosgd.UUCP

                          - 12 -


- 12 -

     Responding-System: cbosgd.UUCP
     cbosgd:osg,cb,btl,bell,net,fa,to,test
     ucbvax:net,fa,to.ucbvax:L:
     cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
     cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
     sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
     npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
     mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi

応じているシステム: cbosgd.UUCP cbosgd: osg、cb、btl、ベル、ネット、ファ、テストucbvax: to.ucbvax: ネット、ファ、L: cbosg: ネット、ファ、ベル、btl、cb、osg、to.cbosg: to.cbosgb: to.sescent: to.npois: F:/usr/spool/outnews/cbosg cbosgb:osg、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  Senduuname

3.6 Senduuname

     senduuname      (no arguments)

senduuname(議論がありません)

The  "uuname"  program is run, and the output is mailed to
the  author  of the control message (Reply-to, if present,
otherwise From).  This program lists all uucp neighbors of
the  local site.  This information is used to make maps of
the UUCP network.  The sys file is not  the  same  as  the
UUCP   L.sys   file.   The  L.sys  file  should  never  be
transmitted to another party without the  consent  of  the
sites whose passwords are listed therein.

"uuname"プログラムを動かして、コントロールメッセージの作者に出力を郵送する、(そうでなければ、プレゼント、Fromであるなら答える、) このプログラムリストはすべて、ローカル・サイトの隣人をuucpします。 この情報は、UUCPネットワークの地図を作るのに使用されます。 sysファイルはUUCP L.sysファイルと同じではありません。 L.sysファイルはパスワードがそこにリストアップされているサイトの同意なしで別のパーティーに決して送られるべきではありません。

It is optional for a site  to  provide  this  information.
Some  reply  should  be  made to the author of the control
message, so that a transmission error won't be blamed.  It
is  also  permissible for a site to run the uuname program
(or in some other way determine the  uucp  neighbors)  and
edit  the output, either automatically or manually, before
mailing the reply back to the  author.   The  file  should
contain  one  site  per line, beginning with the uucp site
name.  Additional information may be  included,  separated
from the site name by a blank or tab.  The phone number or
password for the site should NOT be included, as the reply
is  considered  to  be  in the public domain.  (The uuname
program will send only the site name and  not  the  entire
contents  of  the  L.sys  file,  thus,  phone  numbers and
passwords are not transmitted.)

サイトがこの情報を提供するのは、任意です。 何らかの回答が、伝送エラーが非難されないように、コントロールメッセージの作者に作られているべきです。 また、サイトがuunameプログラム(ある他の方法で、uucp隣人を決定する)を動かして、出力を編集するのも、自動的か手動で許されています、回答を作者に郵送して戻す前に。 uucpサイト名で始まって、ファイルは1線あたり1つのサイトを含むはずです。 追加情報は、含まれているか、空白でサイト名から分離するか、またはタブで移動するかもしれません。 サイトのための電話番号かパスワードを含むべきではありません、回答が公共の場にあると考えられるとき。 (uunameプログラムはL.sysファイルの全体のコンテンツではなく、サイト名だけを送って、その結果、電話番号とパスワードは伝えられません。)

The purpose of this message is to  generate  and  maintain
UUCP mail routing maps.  Thus, connections over which mail
can be sent using the site!user syntax should be included,
regardless  of whether the link is actually a UUCP link at
the physical level.  If a mail router should  use  it,  it
should   be  included.   Since  all  information  sent  in
response to this message is optional, sites  are  free  to
edit  the  list,  deleting secret or private links they do
not wish to publicise.

このメッセージの目的は、UUCPメールルーティング地図を作って、維持することです。 したがって、どのメールの上にサイトを使用させることができるか接続を!ユーザ構文は含まれるべきです、リンクが実際に物理的なレベルにおいてUUCPリンクであるかどうかにかかわらず。 メールルータがそうするなら、それを使用してください、そして、それは含まれるべきです。 このメッセージに対応して送られたすべての情報が任意であるので、サイトは無料でリストを編集できます、それらが宣伝したがっていない秘密の、または、個人的なリンクを削除して。

3.7  Version

3.7 バージョン

     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 article
(Reply-to if present, otherwise From).

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

                          - 13 -


- 13 -

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 ARPANET, 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 article, 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 article on the standard input.)

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

It is not  a  requirement  that  USENET  sites  have  mail
systems  capable  of  understanding the ARPA 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  site 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  site  generating  or  forwarding  news
messages must have an internet address that allows them to
receive mail from sites with internet  mailers,  and  they
must include their internet address on their From line.

USENETサイトがメールシステムをARPAインターネット・メール構文を理解できるようにするという要件ではありませんが、それは強く推薦されます。 From以来Reply、-、回答は、インターネット郵送者なしでSender線がインターネット構文を使用するか、難しいか、または不可能になるでしょう。 インターネット郵送者のないサイトは、回答にPathヘッダー線を使用するのを試みることができますが、この分野は、回答のための働く経路になるように保証されません。 とにかく、ニュースメッセージを発生するか、または転送するどんなサイトも彼らがインターネット郵送者と共にサイトからメールを受け取ることができるインターネットアドレスを持たなければなりません、そして、彼らは彼らの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 article on the standard input.  For
example,  if  the remote system is called  "remote",  news
would be sent over a UUCP link with the  command   "uux  -
remote!rnews",   and on a Berknet,   "net -mremote rnews".
It is important that the article be sent  via  a  reliable
mechansim, 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  article  will   never   be
delivered.   If the article is spooled, it will eventually
be delivered when both systems are up.

ダイレクトリモートコマンド実行を可能にするネットワークもあります。 これらのネットワークでは、標準の入力に関する記事でrnewsコマンドをスプールすることによって、ニュースを転送するかもしれません。 例えば、リモートシステムを「リモートである」と呼ぶなら、コマンドとのUUCPリンクの上にニュースを送るだろう、「uux--リモートで!、rnews、」 Berknet、「ネットの-mremote rnews」で。 信頼できるmechansimを通して記事を送るのは重要です、通常、リアルタイムのリモート実行を指示するよりむしろスプールする可能性にかかわって。 これはリモートシステムがダウンしていると、ダイレクト実行命令が失敗して、記事を決して送らないからです。 両方のシステムが結局上がっているとき、記事をスプールすると、それを届けるでしょう。

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 article 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"に送られます。

                          - 14 -


- 14 -

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 article.  Another  problem  is  that  error  messages
caused  by  the  mail  transmission  would  be sent to the
originator of the news article, who has  no  control  over
news  transmission  between two cooperating hosts and does
not know who  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
article  into a mail message, such that the entire article
(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 article,  and  then  attaching  whatever  mail
headers  are convenient to generate.  The N's are attached
to prevent any special lines  in  the  news  article  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 article.  A program
on the  receiving  machine  receives  mail  to    "rnews",
extracting  the  article itself and invoking the   "rnews" 
program.  An example in this format might look like this:

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

     Date: Monday, 3-Jan-83 08:33:47 MST
     From: news@cbosgd.UUCP
     Subject: network news article
     To: rnews@npois.UUCP

日付: 山地標準時1983年1月3日月曜日8時33分47秒From: news@cbosgd.UUCP Subject: ネットニュース記事To: rnews@npois.UUCP

     NRelay-Version: B 2.10  2/13/83 cbosgd.UUCP
     NPosting-Version: B 2.9 6/21/82 sask.UUCP
     NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
     NFrom: derek@sask.UUCP (Derek Andrew)
     NNewsgroups: net.test
     NSubject: necessary test
     NMessage-ID: <176@sask.UUCP>
     NDate: Monday, 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

NRelay-バージョン: B2.10 2/13/83のcbosgd.UUCP NPosting-バージョン: B2.9 6/21/82sask.UUCP NPath: cbosgd!mhuxj!harpo!utah-Cs!sask!derek NFrom: derek@sask.UUCP (デリック・アンドリュー)NNewsgroups: net.test 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  article) and makes it
harder for software to give different priorities  to  news
and mail.

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

                          - 15 -


- 15 -

4.3  Batching

4.3 バッチング

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

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

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

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

     ##! rnews 1234

##! rnews1234

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

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

      #! rnews 374
      Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
      Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
      Path: cbosgd!mhuxj!mhuxt!eagle!jerry
      From: jerry@eagle.uucp (Jerry Schwarz)
      Newsgroups: net.general
      Subject: Usenet Etiquette -- Please Read
      Message-ID: <642@eagle.UUCP>
      Date: Friday, 19-Nov-82 16:14:55 EST

#! rnews374Relay-バージョン: バージョンB 2.10 2/13/83。 サイトcbosgd.UUCP Posting-バージョン: バージョンB 2.10 2/13/83。 サイトeagle.UUCP Path: cbosgd!mhuxj!mhuxt!ワシ!jerry From: jerry@eagle.uucp (ジェリー・シュワーツ)ニュースグループ: net.general Subject: Usenetエチケット--Message IDを読んでください: <642@eagle.UUCP>日付: 東部標準時1982年11月19日金曜日16時14分55秒

      Here is an important message about USENET Etiquette.
      #! rnews 378
      Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
      Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
      Path: cbosgd!mhuxj!mhuxt!eagle!jerry
      From: jerry@eagle.uucp (Jerry Schwarz)
      Newsgroups: net.followup
      Subject: Notes on Etiquette article
      Message-ID: <643@eagle.UUCP>
      Date: Friday, 19-Nov-82 17:24:12 EST

ここに、USENET Etiquetteに関する重要なメッセージがあります。 #! rnews378Relay-バージョン: バージョンB 2.10 2/13/83。 サイトcbosgd.UUCP Posting-バージョン: バージョンB 2.10 2/13/83。 サイトeagle.UUCP Path: cbosgd!mhuxj!mhuxt!ワシ!jerry From: jerry@eagle.uucp (ジェリー・シュワーツ)ニュースグループ: net.followup Subject: Etiquette記事Message-IDに関する注: <643@eagle.UUCP>日付: 東部標準時1982年11月19日金曜日17時24分12秒

      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ニュースは認識されます。 そして、メッセージは解釈のために「非-バッチャー」に通過されます。

                          - 16 -


- 16 -

5.  The News Propagation Algorithm

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

This section describes the overall scheme  of  USENET  and
the algorithm followed by sites in propagating news to the
entire  network.   Since  all  sites   are   affected   by
incorrectly  formatted articles 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,  each  arc  in the graph is a transmission
path from one host to another host.  Each arc is  labelled
with  a  newsgroup  pattern,  specifying  which  newsgroup
classes are forwarded along  that  link.   Most  arcs  are
bidirectional,  that  is,  if  site  A  sends  a  class of
newsgroups to site B, then site B usually sends  the  same
class  of  newsgroups to site 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  as   "net"   or   "btl".   The special subnet
"net"   is defined to be USENET, although the union of all
subnets may be a superset of USENET (because of sites that
get local newsgroup classes but do not get net.all).  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 sites to be unable to post articles reaching the rest
of the network.)

USENETは多くのサブネットワークで作られます。 各サブネットには、「ネット」か"btl"などの名前があります。 特別なサブネット「ネット」はUSENETになるように定義されます、すべてのサブネットの組合がUSENET(地方のニュースグループのクラスを得ますが、net.allを手に入れないサイトによる)のスーパーセットであるかもしれませんが。 各サブネットが接続グラフである、すなわち、経路はサブネットであらゆるノードから他のあらゆるノードまで存在しています。 さらに、全体のグラフは(理論的に)接続されます。 (実際には、いくつかの政治上の問題が、いくつかのサイトがネットワークの残りに達しながら記事を掲示できないことを引き起こしました。)

An  article  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
site  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
sites  receiving  the  incoming article examine it to make
sure they really want the article, accept it locally,  and
then  in  turn forward the article to all their interest
neighbors.   This  process  continues  until  the   entire
network has seen the article.

記事は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 site  A  sends
an  article to site B, site B will send it back to site A,
which will send it to site B, and so on.  One solution  to
this  is  the history mechanism.  Each site keeps track of
all articles  it  has  seen  (by  their  message  ID)  and
whenever an article comes in that it has already seen, the
incoming article is discarded immediately.  This  solution
is   sufficient   to   prevent   loops,   but   additional
optimizations can be made to  avoid  sending  articles  to
sites that will simply throw them away.

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

                          - 17 -


- 17 -

One optimization is that an article 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 article originated on site A, then site  A
has   already  seen  the  article.   (Origination  can  be
determined by the Posting-Version line.)

1つの最適化はヘッダーのPath線で記載されたマシンに記事を決して送るべきでないということです。 Path線にマシン名があるとき、メッセージがマシンを通り抜けたのが知られています。 別の最適化は次に、記事が現場のAを溯源したならサイトAが既に記事を見たということです。 (創作はPosting-バージョン線で決定できます。)

Thus, if an article is posted to  newsgroup    "net.misc",
it  will match the pattern  "net.all"  (where  "all"  is a
metasymbol that matches any string), and will be forwarded
to  all  sites that subscribe to net.all (as determined by
what their neighbors send them).  These sites make up  the
"net"   subnetwork.   An article posted to   "btl.general" 
will reach all sites receiving  "btl.all",  but  will  not
reach  sites  that do not get  "btl.all".   In effect, the
articles  reaches  the   "btl"   subnetwork.   An  article
posted  to newsgroups  "net.micro,btl.general"  will reach
all sites subscribing to either of the two classes.

したがって、ニュースグループ"net.misc"に記事を掲示すると、それをパターン"net.all"(「すべて」がどんなストリングにも合っているmetasymbolであるところ)を合わせて、net.allに加入するすべてのサイトに送るでしょう(彼らの隣人が彼らを送ることで決定するように)。 これらのサイトは「ネット」のサブネットワークを作ります。 "btl.general"に掲示された記事は、"btl.all"を受けながらすべてのサイトに達しますが、"btl.all"を得ないサイトは達しないでしょう。 事実上、記事は"btl"サブネットワークに達します。 ニュースグループ「net.micro、btl.general」に掲示された記事は2つのクラスのどちらかに加入するすべてのサイトに達するでしょう。

                          - 18 -

- 18 -