RFC1036 日本語訳
1036 Standard for interchange of USENET messages. M.R. Horton, R.Adams. December 1987. (Format: TXT=46891 bytes) (Obsoletes RFC0850) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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ページ]
一覧
スポンサーリンク