RFC2980 日本語訳
2980 Common NNTP Extensions. S. Barber. October 2000. (Format: TXT=57165 bytes) (Updated by RFC3977, RFC4643, RFC4644) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Barber Request for Comments: 2980 Academ Consulting Services Category: Informational October 2000
コメントを求めるワーキンググループS.バーバー要求をネットワークでつないでください: 2980年のAcademコンサルタント業務カテゴリ: 情報の2000年10月
Common NNTP Extensions
一般的なNNTP拡張子
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
In this document, a number of popular extensions to the Network News Transfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. In the role, this document would hopefully create the possibility for some level of interoperability among implementations that make use of extensions.
本書では、RFC977で定義されたネットワークの電子情報を転送するプロトコル(NNTP)プロトコルへの多くのポピュラーな拡大について、記録されて、議論します。 このドキュメントがどんな種類の規格としても機能することを意図していない間、それは希望をいだいてNNTPプロトコルの将来のimplementersのための参考書類として機能するでしょう。 役割では、このドキュメントは何らかのレベルの相互運用性のために希望をいだいて拡大を利用する実装の中で可能性を作成するでしょう。
Introduction
序論
RFC 977 [1] defines the NNTP protocol and was released over a decade ago. Since then, NNTP has become one of the most popular protocols in use on the Internet. Many implementations of the protocol have been created on many different platforms and operating systems. With the growth in use of the protocol, work began on a revision to NNTP in 1991, but that work did not result in a new standard protocol specification. However, many ideas from that working group did find their way into many implementations of NNTP. Additionally, many other extensions, often created by newsreader authors, are also in use. This document will capture and define all known extensions to NNTP available in official NNTP server releases of some type as of this writing. Where possible, the server software first implementing a particular extension will be noted. It is the hope of the author that using this document in tandem with RFC 977 will limit the addition of new extensions that essentially do the same thing. Software developers may wish to use this document and others [2] as a resource for the development of new software.
RFC977[1]はNNTPプロトコルを定義して、10年以上前にリリースされました。 それ以来、NNTPはインターネットで使用中の最もポピュラーなプロトコルの1つになっています。 多くの異なったプラットホームとオペレーティングシステムにプロトコルの多くの実装を作成してあります。プロトコルで使用中の成長で、仕事は改正のときに1991年のNNTPに始まりましたが、その仕事は新しい標準プロトコル仕様をもたらしませんでした。 しかしながら、そのワーキンググループからの多くの考えがNNTPの多くの実装に届きました。 また、さらに、他の多くのしばしばニュースキャスターの作者によって作成された拡大も使用中です。 このドキュメントは、この書くこと付けでタイプの公式のNNTPサーバリリースで利用可能なNNTPとすべての知られている拡大を得て、定義するでしょう。 可能であるところでは、最初に特定の拡大を実装するサーバソフトウェアが述べられるでしょう。 それはRFC977と提携してこのドキュメントを使用すると本質的には同じことをする新しい拡大の追加が制限されるという作者の望みです。 ソフトウェア開発者は新しいソフトウェアの開発にリソースとしてこのドキュメントと他のもの[2]を使用したがっているかもしれません。
Barber Informational [Page 1] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[1ページ]のRFC2980
This document does not specify an Internet Standard of any kind. It only attempts to document current practices. While this document may clarify some ambiguity in RFC 977, RFC 977 should be regarded as authoritative in all cases. There are some implementations that are not strictly RFC 977 compliant and where necessary, these deviations from the standard will be noted. This document does reflect the work of the IETF NNTP-EXT working group chaired by Ned Freed and Stan Barber.
このドキュメントはどんな種類のインターネットStandardも指定しません。 それは、現在の実務を記録するのを試みるだけです。 このドキュメントがRFC977の何らかのあいまいさをはっきりさせているかもしれない間、RFC977はすべての場合で正式であると見なされるべきです。 いくつかの厳密にRFC977対応でない実装があります、そして、必要であるところでは、規格からのこれらの逸脱が述べられるでしょう。 このドキュメントはネッド・フリードとスタン・バーバーによってまとめられたIETF NNTP-EXTワーキンググループの仕事を反映します。
This document is provided to help implementers have a uniform source of information about extensions, however, it is important for any prospective implementer to understand that the extensions listed here are NOT part of any current standard for NNTP. In fact, some of the ones listed in this document should not be included in new NNTP implementations as they should no longer be used modern NNTP environments. Such commands should be considered historic and are documented as such in this document.
implementersには拡大の情報の一定の源があるのを助けるためにこのドキュメントを提供して、しかしながら、どんな将来のimplementerも、ここに記載された拡大がNNTPのどんな現在の規格の一部でないことも理解しているのは、重要です。 事実上、それらがもう中古の現代のNNTP環境であるべきでないので、新しいNNTP実装に本書では記載されたもののいくつかを含むべきではありません。 そのようなコマンドは、歴史的であると考えられるべきであり、そういうものとして本書では記録されます。
Extensions fall into three categories: transport, newsreader and other. Transport extensions are additions to the NNTP specification that were made specifically to move news articles from one server to another server. Newsreader extensions are additions to the NNTP specification that were made to assist NNTP clients in selecting and retrieving news articles from servers. Other extensions to the NNTP specification are those which did not specifically fall into either of the other two categories. Examples of other extensions include authentication and time-of-day extensions. For each command, the format of section 3 of RFC 977 will be used.
拡大は3つのカテゴリになります: ニュースキャスターの、そして、他の輸送。 輸送拡大はニュース記事が特に1つのサーバから別のサーバまで動かさされたNNTP仕様への追加です。ニュースキャスター拡大はNNTPクライアントがサーバからのニュース記事を選択して、検索するのに助けさせられたNNTP仕様への追加です。 NNTP仕様への他の拡大は明確に落ちなかった他の2つのカテゴリのものです。 他の拡大に関する例は認証と時刻拡大を含んでいます。 各コマンドのために、RFC977のセクション3の形式は使用されるでしょう。
1. Transport Extensions
1. 輸送拡大
A transport extension is one which is primarily used in inter-server communications. Following are the descriptions of each transport extension commands and the responses which will be returned by those commands.
輸送拡大は相互サーバコミュニケーションで主として使用されるものです。 以下に、拡大が命令するそれぞれの輸送の記述とそれらのコマンドで返される応答があります。
Each command is shown in upper case for clarity, although case is ignored in the interpretation of commands by the NNTP server. Any parameters are shown in lower case. A parameter shown in [square brackets] is optional. For example, [GMT] indicates that the triglyph GMT may present or omitted. A parameter that may be repeated is followed by an ellipsis.
各コマンドは明快ために大文字で示されます、ケースがNNTPサーバによってコマンドの解釈で無視されますが。どんなパラメタも小文字で示されます。 [角括弧]で示されたパラメタは任意です。 例えば、[グリニッジ標準時] グリニッジ標準時のトリグリフが提示するかもしれないのを示すか、または忘れられます。 省略は繰り返されるかもしれないパラメタのあとに続いています。
Barber Informational [Page 2] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[2ページ]のRFC2980
1.1.1 The CHECK command
1.1.1 CHECKコマンド
CHECK <message-id>
<メッセージイド>をチェックしてください。
CHECK is used by a peer to discover if the article with the specified message-id should be sent to the server using the TAKETHIS command. The peer does not have to wait for a response from the server before sending the next command.
CHECKは、指定されたメッセージイドがある記事がTAKETHISコマンドを使用することでサーバに送られるべきであるかどうか発見するのに同輩によって使用されます。 次のコマンドを送る前に、同輩はサーバから応答を待つ必要はありません。
From using the responses to the sequence of CHECK commands, a list of articles to be sent can be constructed for subsequent use by the TAKETHIS command.
CHECKコマンドの系列への応答を使用するので、その後の使用のためにTAKETHISコマンドで送られる商品目録は構成できます。
The use of the CHECK command for streaming is optional. Some implementations will directly use the TAKETHIS command and send all articles in the send queue on that peer for the server.
CHECKコマンドのストリーミングの使用は任意です。 いくつかの実装が、サーバのために直接TAKETHISコマンドを使用して、その同輩における送信キューにおけるすべての記事を送るでしょう。
On some implementations, the use of the CHECK command is not permitted when the server is in slave mode (via the SLAVE command).
スレーブモード(SLAVEコマンドを通した)でサーバがあるとき、いくつかの実装では、CHECKコマンドの使用は受入れられません。
Responses that are of the form X3X must specify the message-id in the response.
フォームX3Xのものである応答は応答におけるメッセージイドを指定しなければなりません。
1.1.2. Responses
1.1.2. 応答
238 no such article found, please send it to me
400 not accepting articles
431 try sending it again later
438 already have it, please don't send it to me
480 Transfer permission denied
500 Command not understood
そのような238の記事が見つけられないで、それを送ってください、431が再びそれを送ってみるという受諾記事ではなく、400後に私に、438は既にそれを持って、私へのTransfer許可が、500Commandが理解していなかったことを否定した480をそれに送らないでください。
1.2.1 The MODE STREAM command
1.2.1 MODE STREAMコマンド
MODE STREAM
モードストリーム
MODE STREAM is used by a peer to indicate to the server that it would like to suspend the lock step conversational nature of NNTP and send commands in streams. This command should be used before TAKETHIS and CHECK. See the section on the commands TAKETHIS and CHECK for more details.
MODE STREAMは、ストリームこのコマンドにおけるNNTPと発信コマンドの会話の本質がそうするべきであるロックステップがTAKETHISとCHECKの前で使用されるのをそれが中断させたがっているサーバに示すのに同輩によって使用されます。 その他の詳細に関してコマンドのTAKETHISとCHECKの上のセクションを見てください。
1.2.2. Responses
1.2.2. 応答
203 Streaming is OK
500 Command not understood
203ストリーミングはCommandが理解していなかったOK500です。
Barber Informational [Page 3] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[3ページ]のRFC2980
1.3.1 The TAKETHIS command
1.3.1 TAKETHISコマンド
TAKETHIS <message-id>
TAKETHIS<メッセージイド>。
TAKETHIS is used to send articles to a server when in streaming mode. The entire article (header and body, in that sequence) is sent immediately after the peer sends the TAKETHIS command. The peer does not have to wait for a response from the server before sending the next command and the associated article.
ストリーミングのモードで使用するとき、TAKETHISは、記事をサーバに送るのに使用されます。 同輩がTAKETHISコマンドを送る直後全体の記事(ヘッダーとその系列のボディー)を送ります。 次のコマンドと関連記事を送る前に、同輩はサーバから応答を待つ必要はありません。
During transmission of the article, the peer should send the entire article, including header and body, in the manner specified for text transmission from the server. See RFC 977, Section 2.4.1 for details.
記事の伝達の間、同輩は全体の記事を送るべきです、ヘッダーとボディーを含んでいて、サーバからテキスト伝送に指定された方法で。詳細に関してRFC977、セクション2.4.1を見てください。
Responses that are of the form X3X must specify the message-id in the response.
フォームX3Xのものである応答は応答におけるメッセージイドを指定しなければなりません。
1.3.2. Responses
1.3.2. 応答
239 article transferred ok
400 not accepting articles
439 article transfer failed
480 Transfer permission denied
500 Command not understood
239 第439条記事転送を受け入れないわたっている間違いない第400条が許可が、500Commandが理解していなかったことを否定した480Transferに失敗しました。
1.4.1 The XREPLIC command
1.4.1 XREPLICコマンド
XREPLIC ggg:nnn[,ggg:nnn...]
XREPLIC ggg: nnn[ggg: nnn]
The XREPLIC command makes is possible to exactly duplicate the news spool structure of one server in another server. It first appeared in INN.
コマンドが作るXREPLICはまさに別のサーバの1つのサーバのニューススプール構造をコピーするのにおいて可能です。それは最初に、INNに現れました。
This command works similarly to the IHAVE command as specified in RFC 977. The same response codes are used. The command line arguments consist of entries separated by a single comma. Each entry consists of a news group name, a colon, and an article number. If the server responds with a 335 response, the article should be filed in the news group(s) and article number(s) specified in the XREPLIC command line. If the server cannot do successfully install the article once it has accepted it, a 436 or 437 response code can be used to indicate the failure.
このコマンドは同様にRFC977の指定されるとしてのIHAVEコマンドに取り組みます。 同じ応答コードは使用されています。 コマンドライン議論はただ一つのコンマによって切り離されたエントリーから成ります。 各エントリーはニュースグループ名、コロン、および記事番号から成ります。 サーバが335応答で反応するなら、記事はXREPLICコマンドラインで指定されたニュース・グループと記事番号でファイルされるべきです。 いったんそれを受け入れるとサーバが首尾よく記事をインストールできないなら、失敗を示すのに436か437応答コードを使用できます。
This command should only be used when the receiving server is being fed by only one other server. It is likely that when used with servers that have multiple feeds that this command will frequently fail.
他の1つのサーバだけで受信サーバを与えているときだけ、このコマンドを使用するべきです。このコマンドは倍数を持っているサーバと共に使用されるとそれが食べられるのに頻繁に失敗しそうでしょう。
Barber Informational [Page 4] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[4ページ]のRFC2980
XREPLIC slaving has been deprecated in INN version 1.7.2 and later. INN now has the ability to slave servers via transparent means, simply by having the article's Xref header transferred. (In previous versions, this header was generated locally and stripped off on outgoing feeds.)
XREPLICの身を粉にして働くのはINNバージョン1.7.2と後で推奨しないです。 INNには、現在、能力が、見え透いた手段を通した奴隷サーバと、単に記事のXrefヘッダーを移させることによって、あります。 (このヘッダーは、外向的な給送で旧バージョンでは、局所的に生成されて、全部はぎ取られました。)
It is likely that future versions of INN will no longer support XREPLIC.
INNの将来のバージョンはもうXREPLICをサポートしそうにないでしょう。
1.4.2. Responses
1.4.2. 応答
235 article transferred ok
335 send article to be transferred. End with <CR-LF>.<CR-LF>
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try again
235 わたっている間違いない第335条は、移すために記事を送ります。 <CR-LF><CR-LF>435記事が欲しくない終わってください--転送が失敗した436をそれに送らないでください--もう一度拒絶された後の437記事を試みてください--再試行しないでください。
2. Newsreader Extensions
2. ニュースキャスター拡大
Newsreader extensions are those which are primarily used by newsreading clients. Following are the descriptions of each newsreader extension commands and the responses which will be returned by those commands.
ニュースキャスター拡大はクライアントをnewsreadingすることによって主として使用されるものです。 以下に、拡大が命令するそれぞれのニュースキャスターの記述とそれらのコマンドで返される応答があります。
Each command is shown in upper case for clarity, although case is ignored in the interpretation of commands by the NNTP server. Any parameters are shown in lower case. A parameter shown in [square brackets] is optional. For example, [GMT] indicates that the triglyph GMT may present or omitted. A parameter that may be repeated is followed by an ellipsis. Mutually exclusive parameters are separated by a vertical bar (|) character. For example, ggg|<message-id> indicates that a group name or a <message-id> may be specified, but not both. Some parameters, notably <message-id>, is case specific. See RFC 1036 for these details.
各コマンドは明快ために大文字で示されます、ケースがNNTPサーバによってコマンドの解釈で無視されますが。どんなパラメタも小文字で示されます。 [角括弧]で示されたパラメタは任意です。 例えば、[グリニッジ標準時] グリニッジ標準時のトリグリフが提示するかもしれないのを示すか、または忘れられます。 省略は繰り返されるかもしれないパラメタのあとに続いています。 相互に排他的なパラメータが縦棒によって切り離される、(|、)、キャラクタ。 例えば、ggg|グループ名か>がそうする<メッセージイドが指定されるのを示しますが、<メッセージイド>はともに示すというわけではありません。 いくつかのパラメタ、著しく<メッセージイド>はケース特有です。 これらの詳細に関してRFC1036を見てください。
Also, certain commands make use of a pattern for selection of multiple news groups. The pattern in all cases is based on the wildmat [4] format introduced by Rich Salz in 1986. Arguments expected to be in wildmat format will be represented by the string wildmat. This format is discussed in detail in section 3.3 of this document.
また、あるコマンドは複数のニュース・グループの品揃えにパターンを利用します。 すべての場合におけるパターンは1986年にリッシュ・ザルツによって導入されたwildmat[4]形式に基づいています。 wildmat形式にはあると予想された議論はストリングwildmatによって表されるでしょう。 このドキュメントのセクション3.3で詳細にこの形式について議論します。
2.1.1 Extensions to the LIST command
2.1.1 LISTコマンドへの拡大
The original LIST command took no arguments in RFC 977 and returned the contents of the active file in a specific format. Since the original newsreaders made use of other information available in the news transport software in addition to the active file, extensions to
オリジナルのLISTコマンドは、RFC977で議論を全く取らないで、特定の形式でアクティブなファイルのコンテンツを返しました。 ニュースキャスターがアクティブなファイルに加えたニュース輸送ソフトウェア、拡大で利用可能な他の情報の使用をしたオリジナル以来
Barber Informational [Page 5] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[5ページ]のRFC2980
the LIST command were created to make that information available to NNTP newsreaders. There may be other extensions to the LIST command that simply return the contents of a file. This approach is suggested over the addition of over verbs. For example, LIST MOTD could be used instead of adding XMOTD.
LISTコマンドは、それをNNTPニュースキャスターにとって、利用可能な情報にするように作成されました。 LISTコマンドへの単にファイルのコンテンツを返す他の拡大があるかもしれません。 このアプローチが追加の上に示される、動詞の上で。 例えば、XMOTDを加えることの代わりにLIST MOTDを使用できました。
2.1.2 LIST ACTIVE
2.1.2 リストアクティブです。
LIST ACTIVE [wildmat]
リストアクティブです。[wildmat]
LIST ACTIVE is exactly the same as the LIST command specified in RFC 977. The responses and the format should exactly match the LIST command without arguments. If the optional matching parameter is specified, the list is limited to only the groups that match the pattern. Specifying a single group is usually very efficient for the server, and multiple groups may be specified by using wildmat patterns (described later in this document), not regular expressions. If nothing is matched an empty list is returned, not an error. This command first appeared in the UNIX reference version.
LIST ACTIVEはまさにLISTコマンドがRFC977で指定したのと同じです。 応答と形式はまさに議論なしでLISTコマンドに合うべきです。 任意の合っているパラメタが指定されるなら、リストはパターンに合っているグループだけに制限されます。 サーバには、通常、ただ一つのグループを指定するのは非常に効率的です、そして、複数のグループが、正規表現ではなく、wildmatパターン(後で本書では説明される)を使用することによって、指定されるかもしれません。 ものが何も取り組まないなら、誤りではなく空のリストを返します。 このコマンドは最初に、UNIX参照バージョンに現れました。
2.1.3 LIST ACTIVE.TIMES
2.1.3 リストACTIVE.TIMES
LIST ACTIVE.TIMES
リストACTIVE.TIMES
The active.times file is maintained by some news transports systems to contain information about the when and who created a particular news group. The format of this file generally include three fields. The first field is the name of the news group. The second is the time when this group was created on this news server measured in seconds since January 1, 1970. The third is the email address of the entity that created the news group. When executed, the information is displayed following the 215 response. When display is completed, the server will send a period on a line by itself. If the information is not available, the server will return the 503 error response. This command first appeared in the UNIX reference version.
何らかのニュースで情報を含むシステムを輸送する、active.timesファイルが保守される特定のニュース・グループを創設した。 一般に、このファイルの形式は3つの分野を含んでいます。 最初の分野はニュース・グループの名前です。 2番目はこのグループが1970年1月1日以来秒に測定されたこのニュースサーバに創設された時です。 3番目はニュース・グループを創設した実体のEメールアドレスです。 実行すると、215応答に続いて、情報を表示します。 ディスプレイが終了しているとき、サーバ自体は期間を系列に送るでしょう。 情報が利用可能でないなら、サーバは503誤り応答を返すでしょう。 このコマンドは最初に、UNIX参照バージョンに現れました。
2.1.3.1 Responses
2.1.3.1 応答
215 information follows
503 program error, function not performed
215 情報は503プログラムエラー、実行されなかった機能に続きます。
2.1.4 LIST DISTRIBUTIONS
2.1.4 リスト配
LIST DISTRIBUTIONS
リスト配
The distributions file is maintained by some news transport systems to contain information about valid values for the Distribution: line in a news article header and about what the values mean. Each line
配ファイルはDistributionのための有効値の情報を含むようにいくつかのニュース輸送システムによって保守されます: ニュース記事ヘッダーと、そして、値が意味することの周りに関して立ち並んでください。 各系列
Barber Informational [Page 6] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[6ページ]のRFC2980
contains two fields, the value and a short explanation on the meaning of the value. When executed, the information is displayed following the 215 response. When display is completed, the server will send a period on a line by itself. If the information is not available, the server will return the 503 error response. This command first appeared in the UNIX reference version.
価値の意味に関する2つの分野、値、および短い説明を含んでいます。 実行すると、215応答に続いて、情報を表示します。 ディスプレイが終了しているとき、サーバ自体は期間を系列に送るでしょう。 情報が利用可能でないなら、サーバは503誤り応答を返すでしょう。 このコマンドは最初に、UNIX参照バージョンに現れました。
2.1.4.1 Responses
2.1.4.1 応答
215 information follows
503 program error, function not performed
215 情報は503プログラムエラー、実行されなかった機能に続きます。
2.1.5 LIST DISTRIB.PATS
2.1.5 リストDISTRIB.PATS
LIST DISTRIB.PATS
リストDISTRIB.PATS
The distrib.pats file is maintained by some news transport systems to contain default values for the Distribution: line in a news article header when posting to particular news groups. This information could be used to provide a default value for the Distribution: line in the header when posting an article. The information returned involves three fields separated by colons. The first column is a weight. The second is a group name or a pattern that can be used to match a group name in the wildmat format. The third is the value of the Distribution: line that should be used when the group name matches and the weight value is the highest. All this processing is done by the news posting client and not by the server itself. The server just provides this information to the client for it to use or ignore as it chooses. When executed, the information is displayed following the 215 response. When display is completed, the server will send a period on a line by itself. If the information is not available, the server will return the 503 error response. This command first appeared in INN.
distrib.patsファイルはDistributionのためのデフォルト値を含むようにいくつかのニュース輸送システムによって保守されます: 特定のニュースにグループを掲示するときにはニュース記事ヘッダーに立ち並んでください。 デフォルト値をDistributionに供給するのにこの情報を使用できました: 記事を掲示するときにはヘッダーに立ち並んでください。 返された情報はコロンによって切り離された3つの野原にかかわります。 最初のコラムは重りです。 2番目は、wildmat形式でグループ名を合わせるのに使用できるグループ名かパターンです。 3番目はDistributionの値です: グループ名が合っていると使用されるべきである系列と重さの値は最も高いです。 サーバ自体ではなく、ニュース任命クライアントがこのすべての処理を完了しています。 サーバは選ぶようにただそれが使用するか、または無視するクライアントにこの情報を提供します。 実行すると、215応答に続いて、情報を表示します。 ディスプレイが終了しているとき、サーバ自体は期間を系列に送るでしょう。 情報が利用可能でないなら、サーバは503誤り応答を返すでしょう。 このコマンドは最初に、INNに現れました。
2.1.5.1 Responses
2.1.5.1 応答
215 information follows
503 program error, function not performed
215 情報は503プログラムエラー、実行されなかった機能に続きます。
2.1.6 LIST NEWSGROUPS
2.1.6 リストニュースグループ
LIST NEWSGROUPS [wildmat]
リストニュースグループ[wildmat]
The newsgroups file is maintained by some news transport systems to contain the name of each news group which is active on the server and a short description about the purpose of each news group. Each line in the file contains two fields, the news group name and a short explanation of the purpose of that news group. When executed, the
ニュースグループは、それぞれのサーバと短い記述のときにそれぞれのニュース・グループの目的に関して活動的なニュース・グループの名前を含むように何らかのニュースでシステムを輸送しますファイルが保守される。 ファイルの各系列はそのニュース・グループの目的の2つの分野、ニュース・グループ名、および短い説明を含んでいます。 実行されると
Barber Informational [Page 7] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[7ページ]のRFC2980
information is displayed following the 215 response. When display is completed, the server will send a period on a line by itself. If the information is not available, the server will return the 503 response. If the optional matching parameter is specified, the list is limited to only the groups that match the pattern (no matching is done on the group descriptions). Specifying a single group is usually very efficient for the server, and multiple groups may be specified by using wildmat patterns (similar to file globbing), not regular expressions. If nothing is matched an empty list is returned, not an error.
215応答に続いて、情報を表示します。 ディスプレイが終了しているとき、サーバ自体は期間を系列に送るでしょう。 情報が利用可能でないなら、サーバは503応答を返すでしょう。 任意の合っているパラメタが指定されるなら、リストはパターンに合っているグループだけに制限されます(グループ記述のときに合わせません)。 サーバには、通常、ただ一つのグループを指定するのは非常に効率的です、そして、複数のグループが、正規表現ではなく、wildmatパターン(globbingをファイルするために同様の)を使用することによって、指定されるかもしれません。 ものが何も取り組まないなら、誤りではなく空のリストを返します。
When the optional parameter is specified, this command is equivalent to the XGTITLE command, though the response code are different.
任意のパラメタが指定されるとき、応答コードは異なっていますが、このコマンドはXGTITLEコマンドに同等です。
215 information follows
503 program error, function not performed
215 情報は503プログラムエラー、実行されなかった機能に続きます。
2.1.7 LIST OVERVIEW.FMT
2.1.7 リストOVERVIEW.FMT
LIST OVERVIEW.FMT
リストOVERVIEW.FMT
The overview.fmt file is maintained by some news transport systems to contain the order in which header information is stored in the overview databases for each news group. When executed, news article header fields are displayed one line at a time in the order in which they are stored in the overview database [5] following the 215 response. When display is completed, the server will send a period on a line by itself. If the information is not available, the server will return the 503 response.
overview.fmtファイルは、ヘッダー情報が各ニュース・グループのための概要データベースに保存されるオーダーを含むようにいくつかのニュース輸送システムによって保守されます。 実行されると、ニュース記事ヘッダーフィールドは215応答に続いて、それらが概要データベース[5]に保存されるオーダーで一度に1つの表示された系列です。 ディスプレイが終了しているとき、サーバ自体は期間を系列に送るでしょう。 情報が利用可能でないなら、サーバは503応答を返すでしょう。
Please note that if the header has the word "full" (without quotes) after the colon, the header's name is prepended to its field in the output returned by the server.
ヘッダーがコロン後に「完全」に(引用文のない)単語を持っているなら、ヘッダーの名前はサーバによって返された出力における分野にprependedされます。
Many newsreaders work better if Xref: is one of the optional fields.
多くのニュースキャスターがXrefであるならうまくいきます: 1つが任意の分野がありますか?
It is STRONGLY recommended that this command be implemented in any server that implements the XOVER command. See section 2.8 for more details about the XOVER command.
このコマンドがXOVERがコマンドであると実装するどんなサーバでも実装されるのは、STRONGLYお勧めです。 XOVERコマンドに関するその他の詳細に関してセクション2.8を見てください。
2.1.7.1 Responses
2.1.7.1 応答
215 information follows
503 program error, function not performed
215 情報は503プログラムエラー、実行されなかった機能に続きます。
Barber Informational [Page 8] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[8ページ]のRFC2980
2.1.8 LIST SUBSCRIPTIONS
2.1.8 リスト購読
LIST SUBSCRIPTIONS
リスト購読
This command is used to get a default subscription list for new users of this server. The order of groups is significant.
このコマンドは、このサーバの新しいユーザにデフォルト株式申込者名簿を届けるのに使用されます。グループの注文は重要です。
When this list is available, it is preceded by the 215 response and followed by a period on a line by itself. When this list is not available, the server returns a 503 response code.
このリストが利用可能であるときに、それは、215応答で先行されていて、系列に関する期間までにそれ自体で続かれています。 このリストが利用可能でないときに、サーバは503応答コードを返します。
2.1.8.1 Responses
2.1.8.1 応答
215 information follows
503 program error, function not performed
215 情報は503プログラムエラー、実行されなかった機能に続きます。
2.2 LISTGROUP
2.2 LISTGROUP
LISTGROUP [ggg]
LISTGROUP[ggg]
The LISTGROUP command is used to get a listing of all the article numbers in a particular news group.
LISTGROUPコマンドは、特定のニュース・グループですべての記事番号のリストを手に入れるのに使用されます。
The optional parameter ggg is the name of the news group to be selected (e.g. "news.software.b"). A list of valid news groups may be obtained from the LIST command. If no group is specified, the current group is used as the default argument.
任意のパラメタgggは選択されるべきニュース・グループ(例えば、"news.software.b")の名前です。 LISTコマンドから有効なニュース・グループのリストを得るかもしれません。 グループが全く指定されないなら、現在のグループはデフォルト議論として使用されます。
The successful selection response will be a list of the article numbers in the group followed by a period on a line by itself.
うまくいっている選択応答は系列でそれ自体で期間までに従われたグループにおける記事番号のリストになるでしょう。
When a valid group is selected by means of this command, the internally maintained "current article pointer" is set to the first article in the group. If an invalid group is specified, the previously selected group and article remain selected. If an empty news group is selected, the "current article pointer" is in an indeterminate state and should not be used.
有効なグループがこのコマンドによって選択されるとき、内部的に維持された「現在の記事指針」はグループにおける最初の記事に設定されます。 無効のグループが指定されるなら、以前に選択されたグループと記事は選択されたままで残っています。 空のニュース・グループを選択するなら、「現在の記事指針」は不確定の状態にあって、使用するべきではありません。
Note that the name of the news group is not case-dependent. It must otherwise match a news group obtained from the LIST command or an error will result.
ニュース・グループの名前がケース依存していないことに注意してください。 そうでなければ、それがLISTコマンドから得られたニュース・グループに合わなければならない、さもなければ、誤りは結果として生じるでしょう。
2.2.1 Responses
2.2.1 応答
211 list of article numbers follow
412 Not currently in newsgroup
502 no permission
211が、数が現在ニュースグループ502で412Notに続くという記事についていいえと記載する、許可
Barber Informational [Page 9] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[9ページ]のRFC2980
2.3 MODE READER
2.3 モード読者
MODE READER is used by the client to indicate to the server that it is a news reading client. Some implementations make use of this information to reconfigure themselves for better performance in responding to news reader commands. This command can be contrasted with the SLAVE command in RFC 977, which was not widely implemented. MODE READER was first available in INN.
MODE READERは、それがニュース読書クライアントであることをサーバに示すのにクライアントによって使用されます。 いくつかの実装が、より良い性能のためにニュース読者コマンドに応じる際に自分たちを再構成するのにこの情報を利用します。 RFC977のSLAVEコマンドに対してこのコマンドを対照できます。(RFCは広く実装されませんでした)。 MODE READERは最初に、INNで利用可能でした。
2.3.1 Responses
2.3.1 応答
200 Hello, you can post
201 Hello, you can't post
200 あなたは、こんにちは、201Helloを掲示できると掲示できません。
2.4 XGTITLE
2.4 XGTITLE
XGTITLE [wildmat]
XGTITLE[wildmat]
The XGTITLE command is used to retrieve news group descriptions for specific news groups.
XGTITLEコマンドは、特定のニュース・グループのためにニュース・グループ記述を検索するのに使用されます。
This extension first appeared in ANU-NEWS, an NNTP implementation for DEC's VMS. The optional parameter is a pattern in wildmat format. When executed, a 282 response is given followed by lines that have two fields, the news group name (which matches the pattern in the argument) and a short explanation of the purpose of the news group. When no argument is specified, the default argument is the current group name. When display is completed, the server sends a period on a line by itself.
この拡大は最初にアーヌー-NEWSに現れました、12月のVMSのためのNNTP実装。任意のパラメタはwildmat形式においてパターンです。 実行すると、2つの分野、ニュースグループ名(議論におけるパターンに合っている)、およびニュース・グループの目的の短い説明を持っている系列があとに続いていて、282応答を与えます。 議論が全く指定されないとき、デフォルト議論は現在のグループ名です。 ディスプレイが終了しているとき、サーバ自体は期間を系列に送ります。
Please note that this command and the LIST NEWSGROUP command provide the same functionality with different response codes.
このコマンドとLIST NEWSGROUPコマンドは異なった応答コードを同じ機能性に提供します。
Since this command provides the same functionality as LIST NEWSGROUP it is suggested that this extension be deprecated and no longer be used in newsreading clients.
このコマンドがLIST NEWSGROUPと同じ機能性を提供するので、この拡張子が推奨しなく、もうクライアントをnewsreadingする際に使用されないことが提案されます。
Note that there is a conflict in one of the response codes from XGTITLE and some of the authentication extensions.
XGTITLEからの応答コードと認証拡大のいくつかの1つには闘争があることに注意してください。
2.5.1 Responses
2.5.1 応答
481 Groups and descriptions unavailable
282 list of groups and descriptions follows
グループと記述の入手できない282リストが従う481のグループと記述
Barber Informational [Page 10] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[10ページ]のRFC2980
2.6 XHDR
2.6 XHDR
XHDR header [range|<message-id>]
XHDRヘッダー[及んでください| <メッセージイド>]
The XHDR command is used to retrieve specific headers from specific articles.
XHDRコマンドは、特定の記事から特定のヘッダーを救済するのに使用されます。
The required parameter is the name of a header line (e.g. "subject") in a news group article. See RFC 1036 for a list of valid header lines. The optional range argument may be any of the following:
必要なパラメタはニュース・グループ記事のヘッダー系列(例えば、「対象」)の名前です。 有効なヘッダー系列のリストに関してRFC1036を見てください。 任意の範囲議論は以下のいずれであるかもしれませんも:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
ダッシュで記事番号が別の記事番号があとに続いたダッシュがあとに続いた記事番号に従って、すべてを示すために続いた記事番号
The optional message-id argument indicates a specific article. The range and message-id arguments are mutually exclusive. If no argument is specified, then information from the current article is displayed. Successful responses start with a 221 response followed by a the matched headers from all matched messages. Each line containing matched headers returned by the server has an article number (or message ID, if a message ID was specified in the command), then one or more spaces, then the value of the requested header in that article. Once the output is complete, a period is sent on a line by itself. If the optional argument is a message-id and no such article exists, the 430 error response is returned. If a range is specified, a news group must have been selected earlier, else a 412 error response is returned. If no articles are in the range specified, a 420 error response is returned by the server. A 502 response will be returned if the client only has permission to transfer articles.
任意のメッセージイド議論は特定の記事を示します。 範囲とメッセージイド議論は互いに排他的です。 議論を全く指定しないなら、現在の記事からの情報を表示します。 うまくいっている応答は取り組んでいるヘッダーによってすべての取り組んでいるメッセージから後をつけられた221応答から始まります。 サーバによって返された取り組んでいるヘッダーを含む各系列が記事番号(または、メッセージIDがコマンドで指定されたなら、IDを通信させる)、次に、1つ以上の空間、次にその記事の要求されたヘッダーの値を持っています。 出力がいったん完全になると、系列でそれ自体で期間を送ります。 任意の議論がメッセージイドであり、何かそのような記事が存在していないなら、430誤り応答を返します。 範囲を指定するなら、より早くニュース・グループを選択したに違いなくて、ほかに、412誤り応答を返します。 記事が全く指定された範囲にないなら、サーバは420誤り応答を返します。クライアントに記事を移す許可があるだけであると、502応答を返すでしょう。
Some implementations will return "(none)" followed by a period on a line by itself if no headers match in any of the articles searched. Others return the 221 response code followed by a period on a line by itself.
記事のどれかのヘッダーマッチが全く探されなかったなら、いくつかの実装自体が系列で期間までに続かれる「(なにも)」を返すでしょう。 他のもの自身は系列で期間までに従われた221応答コードを返します。
The XHDR command has been available in the UNIX reference implementation from its first release. However, until now, it has been documented only in the source for the server.
最初のリリースによって、XHDRコマンドはUNIX参照実装で利用可能です。 しかしながら、現在まで、それはサーバのためにソースだけに記録されました。
Barber Informational [Page 11] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[11ページ]のRFC2980
2.6.1 Responses
2.6.1 応答
221 Header follows
412 No news group current selected
420 No current article selected
430 no such article
502 no permission
グループ電流が420のいいえの現在の記事を選択したという221のヘッダー尾行412いいえニュースがそのような430の第502条ノーを選択しなかった、許可
2.7 XINDEX
2.7 XINDEX
XINDEX ggg
XINDEX ggg
The XINDEX command is used to retrieve an index file in the format of originally created for use by the TIN [6] news reader.
XINDEXコマンドは、使用のためにTIN[6]ニュース読者によって作成された元々の形式で索引ファイルを取るのに使用されます。
The required parameter ggg is the name of the news group to be selected (e.g. "news.software.b"). A list of valid news groups may be obtained from the LIST command.
必要なパラメタgggは選択されるべきニュース・グループ(例えば、"news.software.b")の名前です。 LISTコマンドから有効なニュース・グループのリストを得るかもしれません。
The successful selection response will return index file in the format used by the TIN news reader followed by a period on a line by itself.
うまくいっている選択応答は系列で期間までに続かれるTINニュース読者自身によって使用された形式で索引ファイルを返すでしょう。
When a valid group is selected by means of this command, the internally maintained "current article pointer" is set to the first article in the group. If an invalid group is specified, the previously selected group and article remain selected. If an empty news group is selected, the "current article pointer" is in an indeterminate state and should not be used.
有効なグループがこのコマンドによって選択されるとき、内部的に維持された「現在の記事指針」はグループにおける最初の記事に設定されます。 無効のグループが指定されるなら、以前に選択されたグループと記事は選択されたままで残っています。 空のニュース・グループを選択するなら、「現在の記事指針」は不確定の状態にあって、使用するべきではありません。
Note that the name of the news group is not case-dependent. It must otherwise match a news group obtained from the LIST command or an error will result.
ニュース・グループの名前がケース依存していないことに注意してください。 そうでなければ、それがLISTコマンドから得られたニュース・グループに合わなければならない、さもなければ、誤りは結果として生じるでしょう。
The format of the tin-style index file is discussed in the documentation for the TIN newsreader. Since more recent versions of TIN support the news overview (NOV) format, it is recommended that this extension become historic and no longer be used in current servers or future implementations.
TINニュースキャスターのためにドキュメンテーションでスズスタイル索引ファイルの形式について議論します。 TINの、より最近のバージョンが、ニュース概要(11月)が形式であるとサポートするので、この拡張子が歴史的になって、もう現在のサーバか将来の実装に使用されないのは、お勧めです。
2.7.1 Responses
2.7.1 応答
218 tin-style index follows
418 no tin-style index is available for this news group
218 インデックスが続くスズスタイル418スズスタイルがないインデックスはこのニュース・グループに利用可能です。
Barber Informational [Page 12] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[12ページ]のRFC2980
2.8 XOVER
2.8 XOVER
XOVER [range]
XOVER[範囲]
The XOVER command returns information from the overview database for the article(s) specified. This command was originally suggested as part of the OVERVIEW work described in "The Design of a Common Newsgroup Overview Database for Newsreaders" by Geoff Collyer. This document is distributed in the Cnews distribution. The optional range argument may be any of the following:
コマンドが情報を記事のための概要データベースから返すXOVERは指定しました。 OVERVIEW仕事の一部がジェフCollyerで「ニュースキャスターへの一般的なニュースグループ概要データベースのデザイン」で説明したようにこのコマンドは元々、示されました。 このドキュメントはCnews分配で配布されます。 任意の範囲議論は以下のいずれであるかもしれませんも:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
ダッシュで記事番号が別の記事番号があとに続いたダッシュがあとに続いた記事番号に従って、すべてを示すために続いた記事番号
If no argument is specified, then information from the current article is displayed. Successful responses start with a 224 response followed by the overview information for all matched messages. Once the output is complete, a period is sent on a line by itself. If no argument is specified, the information for the current article is returned. A news group must have been selected earlier, else a 412 error response is returned. If no articles are in the range specified, a 420 error response is returned by the server. A 502 response will be returned if the client only has permission to transfer articles.
議論を全く指定しないなら、現在の記事からの情報を表示します。 うまくいっている応答は224応答から始まります、続いて、すべての取り組んでいるメッセージのための概要情報から始まります。 出力がいったん完全になると、系列でそれ自体で期間を送ります。 議論を全く指定しないなら、現在の記事のための情報を返します。 より早くニュース・グループを選択したに違いなくて、ほかに、412誤り応答を返します。 記事が全く指定された範囲にないなら、サーバは420誤り応答を返します。クライアントに記事を移す許可があるだけであると、502応答を返すでしょう。
Each line of output will be formatted with the article number, followed by each of the headers in the overview database or the article itself (when the data is not available in the overview database) for that article separated by a tab character. The sequence of fields must be in this order: subject, author, date, message-id, references, byte count, and line count. Other optional fields may follow line count. Other optional fields may follow line count. These fields are specified by examining the response to the LIST OVERVIEW.FMT command. Where no data exists, a null field must be provided (i.e. the output will have two tab characters adjacent to each other). Servers should not output fields for articles that have been removed since the XOVER database was created.
出力の各系列はタブキャラクタによって切り離されたその記事のために概要データベースか記事自体のヘッダー各人によって後をつけられた記事番号でフォーマットされるでしょう(概要データベースでデータを得ることができないとき)。 分野の系列がこのオーダーにあるに違いありません: 対象、作者、日付、メッセージイド、参照、バイト・カウント、およびラインカウント。 他の任意の分野はラインカウントに続くかもしれません。 他の任意の分野はラインカウントに続くかもしれません。 これらの分野は、LIST OVERVIEW.FMTコマンドへの応答を調べることによって、指定されます。 データが全く存在しないところに、空フィールドを提供しなければなりません(すなわち、出力には、互いに隣接して2つのタブキャラクタがあるでしょう)。 サーバはそうするべきではありません。XOVERデータベースが作成されて以来取り除かれている記事のための出力フィールド。
The LIST OVERVIEW.FMT command should be implemented if XOVER is implemented. A client can use LIST OVERVIEW.FMT to determine what optional fields and in which order all fields will be supplied by the XOVER command. See Section 2.1.7 for more details about the LIST OVERVIEW.FMT command.
XOVERが実装されるなら、LIST OVERVIEW.FMTコマンドは実装されるべきです。 クライアントは、どんな任意の分野とすべての野原がどのオーダーでXOVERコマンドで供給されるかを決定するのにLIST OVERVIEW.FMTを使用できます。 LIST OVERVIEW.FMTコマンドに関するその他の詳細に関してセクション2.1.7を見てください。
Barber Informational [Page 13] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[13ページ]のRFC2980
Note that any tab and end-of-line characters in any header data that is returned will be converted to a space character.
返されるどんなヘッダー・データのどんなタブと行末文字も間隔文字に変換されることに注意してください。
2.8.1 Responses
2.8.1 応答
224 Overview information follows
412 No news group current selected
420 No article(s) selected
502 no permission
224の概要情報尾行412のニュース・グループの現在の選択された420いいえいいえ記事(s)が502ノー、を選択した、許可
2.9 XPAT
2.9 XPAT
XPAT header range|<message-id> pat [pat...]
XPATヘッダー範囲|>が軽くたたく<メッセージイド[軽くたたきます]
The XPAT command is used to retrieve specific headers from specific articles, based on pattern matching on the contents of the header. This command was first available in INN.
XPATコマンドは特定の記事から特定のヘッダーを救済するのに使用されます、ヘッダーのコンテンツにおけるパターン・マッチングに基づいて。 このコマンドは最初に、INNで利用可能でした。
The required header parameter is the name of a header line (e.g. "subject") in a news group article. See RFC 1036 for a list of valid header lines. The required range argument may be any of the following:
必要なヘッダーパラメタはニュース・グループ記事のヘッダー系列(例えば、「対象」)の名前です。 有効なヘッダー系列のリストに関してRFC1036を見てください。 必要な範囲議論は以下のいずれであるかもしれませんも:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
ダッシュで記事番号が別の記事番号があとに続いたダッシュがあとに続いた記事番号に従って、すべてを示すために続いた記事番号
The required message-id argument indicates a specific article. The range and message-id arguments are mutually exclusive. At least one pattern in wildmat must be specified as well. If there are additional arguments the are joined together separated by a single space to form one complete pattern. Successful responses start with a 221 response followed by a the headers from all messages in which the pattern matched the contents of the specified header line. This includes an empty list. Once the output is complete, a period is sent on a line by itself. If the optional argument is a message-id and no such article exists, the 430 error response is returned. A 502 response will be returned if the client only has permission to transfer articles.
必要なメッセージイド議論は特定の記事を示します。 範囲とメッセージイド議論は互いに排他的です。 また、wildmatの少なくとも1つのパターンを指定しなければなりません。 追加議論がある、シングルスペースで切り離された状態で、1つの完全なパターンを形成するために結合します。 うまくいっている応答はヘッダーによってパターンが指定されたヘッダー系列のコンテンツに合っていたすべてのメッセージから後をつけられた221応答から始まります。 これは空のリストを含んでいます。 出力がいったん完全になると、系列でそれ自体で期間を送ります。 任意の議論がメッセージイドであり、何かそのような記事が存在していないなら、430誤り応答を返します。 クライアントに記事を移す許可があるだけであると、502応答を返すでしょう。
2.9.1 Responses
2.9.1 応答
221 Header follows
430 no such article
502 no permission
221ヘッダーがそのような430の第502条ノーに従わない、許可
Barber Informational [Page 14] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[14ページ]のRFC2980
2.10 The XPATH command
2.10 XPATHコマンド
XPATH <message-id>
XPATH<メッセージイド>。
The XPATH command is used to determine the filenames in which an article is filed. It first appeared in INN.
XPATHコマンドは、記事がファイルされるファイル名を決定するのに使用されます。 それは最初に、INNに現れました。
The required parameter message-id is the message id of an article as shown in that article's message-id header. According to RFC 1036 [3], all message ids for all articles within the netnews environment are unique, but articles may be crossposted to multiple groups. The response to an XPATH command will include a listing of all filenames in which an article is stored separated by spaces or a response indicating that no article with the specified message-id exists. The returned data is only useful if the news client knows the implementation details of the server. Because of this, it is recommended that client avoid using this command.
必要なパラメタメッセージイドはその記事のメッセージイドヘッダーに示されるように記事のメッセージイドです。 RFC1036[3]によると、ネットニュース環境の中のすべての記事のためのすべてのメッセージイドがユニークですが、記事は複数のグループにクロスポストされるかもしれません。 XPATHコマンドへの応答は記事が空間によって切り離された状態で保存されるすべてのファイル名のリストか指定されたメッセージイドがある記事が全く存在しないのを示す応答を含むでしょう。 ニュースクライアントがサーバの実装の詳細を知っている場合にだけ、返されたデータは役に立ちます。これのために、クライアントが、このコマンドを使用するのを避けるのは、お勧めです。
2.10.1 Responses
2.10.1 応答
223 path1[ path2 ...]
430 no such article on server
223 path1[path2] サーバに関するそのような430の記事でない
2.11 The XROVER command
2.11 XROVERコマンド
XROVER [range]
XROVER[範囲]
The XROVER command returns reference information from the overview database for the article(s) specified. This command first appeared in the Unix reference implementation. The optional range argument may be any of the following:
コマンドが参考情報を記事のための概要データベースから返すXROVERは指定しました。 このコマンドは最初に、Unix参照実装に現れました。 任意の範囲議論は以下のいずれであるかもしれませんも:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
ダッシュで記事番号が別の記事番号があとに続いたダッシュがあとに続いた記事番号に従って、すべてを示すために続いた記事番号
Successful responses start with a 224 response followed by the contents of reference information for all matched messages. Once the output is complete, a period is sent on a line by itself. If no argument is specified, the information for the current article is returned. A news group must have been selected earlier, else a 412 error response is returned. If no articles are in the range specified, a 420 error response is returned by the server. A 502 response will be returned if the client only has permission to transfer articles.
うまくいっている応答は224応答から始まります、続いて、すべての取り組んでいるメッセージのための参考情報のコンテンツから始まります。 出力がいったん完全になると、系列でそれ自体で期間を送ります。 議論を全く指定しないなら、現在の記事のための情報を返します。 より早くニュース・グループを選択したに違いなくて、ほかに、412誤り応答を返します。 記事が全く指定された範囲にないなら、サーバは420誤り応答を返します。クライアントに記事を移す許可があるだけであると、502応答を返すでしょう。
Barber Informational [Page 15] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[15ページ]のRFC2980
The output will be formatted with the article number, followed by the contents of the References: line for that article, but does not contain the field name itself.
出力はReferencesのコンテンツがあとに続いた記事番号でフォーマットされるでしょう: その記事のためのフィールド名自体を含んでいないのを除いた系列。
This command provides the same basic functionality as using the XHDR command and "references" as the header argument.
このコマンドはヘッダー議論としてXHDRコマンドと「参照」を使用するのと同じ基本機能を提供します。
2.11.1 Responses
2.11.1 応答
224 Overview information follows
412 No news group current selected
420 No article(s) selected
502 no permission
224の概要情報尾行412のニュース・グループの現在の選択された420いいえいいえ記事(s)が502ノー、を選択した、許可
2.12 XTHREAD
2.12 XTHREAD
XTHREAD [DBINIT|THREAD]
XTHREAD[DBINIT| スレッド]
The XTHREAD command is used to retrieve threading information in format of originally created for use by the TRN [6] news reader.
XTHREADコマンドは、使用のためにTRN[6]ニュース読者によって作成された元々の形式における縫うように通る情報を検索するのに使用されます。
The command XTHREAD DBINIT may be issued prior to entering any groups to see if a thread database exists. If it does, the database's byte order and version number are returned as binary data.
スレッドデータベースが存在するかどうか確認するためにどんなグループにも入る前に、コマンドXTHREAD DBINITは発行されるかもしれません。 そうするなら、データベースのバイトオーダーとバージョン番号はバイナリ・データとして返されます。
If no parameter is given, XTHREAD THREAD is assumed.
パラメタを全く与えないなら、XTHREAD THREADを想定します。
To use XTHREAD THREAD, a news group must have been selected earlier, else a 412 error response is returned.
XTHREAD THREADを使用するために、より早くニュース・グループを選択したに違いなくて、ほかに、412誤り応答を返します。
A 502 response will be returned if the client only has permission to transfer articles. A 503 response is returned if the threading files are not available.
クライアントに記事を移す許可があるだけであると、502応答を返すでしょう。 縫うように通るファイルが利用可能でないなら、503応答を返します。
The format of the trn-style thread format is discussed in the documentation for the TRN newsreader. Since more recent versions of TRN support the news overview (NOV) format, it is recommended that this extension become historic and no longer be used in current servers or future implementations.
TRNニュースキャスターのためにドキュメンテーションでtrn-スタイルスレッド形式の形式について議論します。 TRNの、より最近のバージョンが、ニュース概要(11月)が形式であるとサポートするので、この拡張子が歴史的になって、もう現在のサーバか将来の実装に使用されないのは、お勧めです。
2.12.1 Responses
2.12.1 応答
288 Binary data to follow
412 No newsgroup current selected
502 No permission
503 program error, function not performed
412いいえニュースグループ電流に続く288バイナリ・データは502いいえ許可503プログラムエラーを選択して、機能は働きませんでした。
Barber Informational [Page 16] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[16ページ]のRFC2980
3. Other Extensions
3. 他の拡大
3.1 AUTHINFO
3.1 AUTHINFO
AUTHINFO is used to inform a server about the identity of a user of the server. In all cases, clients must provide this information when requested by the server. Servers are not required to accept authentication information that is volunteered by the client. Clients must accommodate servers that reject any authentication information volunteered by the client.
AUTHINFOは、サーバのユーザのアイデンティティに関するサーバを知らせるのに使用されます。ケースでありサーバによって要求されると、全部で、クライアントはこの情報を前提としなければなりません。サーバは、クライアントによって進んで提供される認証情報を受け入れるのに必要ではありません。 クライアントはクライアントによって進んで提供されたどんな認証情報も拒絶するサーバを収容しなければなりません。
There are three forms of AUTHINFO in use. The original version, an NNTP v2 revision called AUTHINFO SIMPLE and a more recent version which is called AUTHINFO GENERIC.
使用中のAUTHINFOの3つのフォームがあります。 オリジナルバージョン、AUTHINFO SIMPLEと呼ばれるNNTP v2改正、およびAUTHINFO GENERICと呼ばれるより最近のバージョン。
3.1.1 Original AUTHINFO
3.1.1 オリジナルのAUTHINFO
AUTHINFO USER username AUTHINFO PASS password
AUTHINFO USERユーザ名AUTHINFO PASSパスワード
The original AUTHINFO is used to identify a specific entity to the server using a simple username/password combination. It first appeared in the UNIX reference implementation.
オリジナルのAUTHINFOは、簡単なユーザーネーム/パスワード組み合わせを使用することで特定の実体をサーバに特定するのに使用されます。 それは最初に、UNIX参照実装に現れました。
When authorization is required, the server will send a 480 response requesting authorization from the client. The client must enter AUTHINFO USER followed by the username. Once sent, the server will cache the username and may send a 381 response requesting the password associated with that username. Should the server request a password using the 381 response, the client must enter AUTHINFO PASS followed by a password and the server will then check the authentication database to see if the username/password combination is valid. If the combination is valid or if no password is required, the server will return a 281 response. The client should then retry the original command to which the server responded with the 480 response. The command should then be processed by the server normally. If the combination is not valid, the server will return a 502 response.
承認が必要であるときに、サーバで、480応答はクライアントから承認を要求するでしょう。 クライアントはAUTHINFO USERに入らなければなりません、続いて、ユーザ名に入ります。 一度送ります、サーバで、381応答はユーザ名をキャッシュして、そのユーザ名に関連しているパスワードを要求するかもしれません。 サーバは381応答を使用することでパスワードを要求するべきです、そして、クライアントはパスワードがあとに続いたAUTHINFO PASSに入らなければなりません、そして、次に、サーバはユーザーネーム/パスワード組み合わせが有効であるかどうか確認するために認証データベースをチェックするでしょう。 組み合わせが有効であるか、またはパスワードは全く必要でないなら、サーバが281応答を返すでしょう。 そして、クライアントはサーバが480応答で反応したオリジナルのコマンドを再試行するべきです。 そして、通常、コマンドはサーバによって処理されるはずです。 組み合わせが有効でないなら、サーバは502応答を返すでしょう。
Clients must provide authentication when requested by the server. It is possible that some implementations will accept authentication information at the beginning of a session, but this was not the original intent of the specification. If a client attempts to reauthenticate, the server may return 482 response indicating that the new authentication data is rejected by the server. The 482 code will also be returned when the AUTHINFO commands are not entered in the correct sequence (like two AUTHINFO USERs in a row, or AUTHINFO PASS preceding AUTHINFO USER).
サーバによって要求されると、クライアントは認証を提供しなければなりません。いくつかの実装がセッションの始めに認証情報を受け入れるのは、可能ですが、これは仕様の当初の意図ではありませんでした。 reauthenticate、クライアントが、試みるなら、サーバは新しい認証データがサーバによって拒絶されるのを示すリターン482応答がそうするかもしれなくて、AUTHINFOが命令するとき、またコードが返される482は正しい系列に入れられません(並んでいる2AUTHINFO USERs、またはAUTHINFO USERに先行するAUTHINFO PASSのように)。
Barber Informational [Page 17] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[17ページ]のRFC2980
All information is passed in cleartext.
すべての情報がcleartextで通過されます。
When authentication succeeds, the server will create an email address for the client from the user name supplied in the AUTHINFO USER command and the hostname generated by a reverse lookup on the IP address of the client. If the reverse lookup fails, the IP address, represented in dotted-quad format, will be used. Once authenticated, the server shall generate a Sender: line using the email address provided by authentication if it does not match the client-supplied From: line. Additionally, the server should log the event, including the email address. This will provide a means by which subsequent statistics generation can associate newsgroup references with unique entities - not necessarily by name.
認証が成功すると、サーバはクライアントのためにAUTHINFO USERコマンドで提供されたユーザ名前とクライアントのIPアドレスに関する逆のルックアップによって生成されたホスト名からEメールアドレスを作成するでしょう。 逆のルックアップが失敗すると、点を打たされた回路形式で表されたIPアドレスは使用されるでしょう。 いったん認証されると、サーバはSenderを生成するものとします: クライアントに供給に合っていないなら認証で提供されたEメールアドレスを使用することで立ち並んでください、From: 立ち並んでください。 さらに、サーバはEメールアドレスを含むイベントを登録するべきです。 これはその後の統計世代が必ず名前ではなく、ユニークな実体にニュースグループ参照を関連づけることができる手段を提供するでしょう。
3.1.1.1 Responses
3.1.1.1 応答
281 Authentication accepted
381 More authentication information required
480 Authentication required
482 Authentication rejected
502 No permission
281 認証の受け入れられた381More認証情報必要な480のAuthenticationの必要な482Authenticationは502いいえ許可を拒絶しました。
3.1.2 AUTHINFO SIMPLE
3.1.2 AUTHINFO簡単です。
AUTHINFO SIMPLE user password
AUTHINFO SIMPLEユーザパスワード
This version of AUTHINFO was part of a proposed NNTP V2 specification, which was started in 1991 but never completed, and is implemented in some servers and clients. It is a refinement of the original AUTHINFO and provides the same basic functionality, but the sequence of commands is much simpler.
AUTHINFOのこのバージョンは提案されたNNTP V2仕様の一部でした。(それは、1991年に始められましたが、決して完成しないで、何人かのサーバとクライアントで履行されます)。 それは、オリジナルのAUTHINFOの気品であり、同じ基本機能を提供しますが、コマンドの系列ははるかに簡単です。
When authorization is required, the server sends a 450 response requesting authorization from the client. The client must enter AUTHINFO SIMPLE. If the server will accept this form of authentication, the server responds with a 350 response. The client must then send the username followed by one or more space characters followed by the password. If accepted, the server returns a 250 response and the client should then retry the original command to which the server responded with the 450 response. The command should then be processed by the server normally. If the combination is not valid, the server will return a 452 response.
承認が必要であるときに、サーバで、450応答はクライアントから承認を要求します。 クライアントはAUTHINFO SIMPLEに入らなければなりません。 サーバがこの形式の認証を受け入れるなら、サーバは350応答で反応します。 次に、クライアントはユーザ名を送らなければなりません、続いて1つ以上の間隔文字を送ります、続いて、パスワードを送ります。 受け入れるなら、サーバは250応答を返します、そして、次に、クライアントはサーバが450応答で反応したオリジナルのコマンドを再試行するべきです。 そして、通常、コマンドはサーバによって処理されるはずです。 組み合わせが有効でないなら、サーバは452応答を返すでしょう。
Note that the response codes used here were part of the proposed NNTP V2 specification and are violations of RFC 977. It is recommended that this command not be implemented, but use either or both of the other forms of AUTHINFO if such functionality if required.
ここで使用された応答コードが提案されたNNTP V2仕様の一部であり、RFC977の違反であることに注意してください。 このコマンドが実装されないのが、お勧めですが、必要なら、そのような機能性であるならAUTHINFOの他のフォームのどちらかか両方を使用してください。
Barber Informational [Page 18] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[18ページ]のRFC2980
3.1.2.1 Responses
3.1.2.1 応答
250 Authorization accepted
350 Continue with authorization sequence
450 Authorization required for this command
452 Authorization rejected
承認系列450Authorizationが452Authorizationが拒絶したこのコマンドに必要である状態で250承認は350Continueを受け入れました。
3.1.3 AUTHINFO GENERIC
3.1.3 AUTHINFOジェネリック
AUTHINFO GENERIC authenticator arguments...
AUTHINFO GENERIC固有識別文字議論…
AUTHINFO GENERIC is used to identify a specific entity to the server using arbitrary authentication or identification protocols. The desired protocol is indicated by the authenticator parameter, and any number of parameters can be passed to the authenticator.
AUTHINFO GENERICは、任意の認証か識別プロトコルを使用することで特定の実体をサーバに特定するのに使用されます。 固有識別文字パラメタで必要なプロトコルを示します、そして、いろいろなパラメタを固有識別文字に通過できます。
When authorization is required, the server will send a 480 response requesting authorization from the client. The client should enter AUTHINFO GENERIC followed by the authenticator name, and the arguments if any. The authenticator and arguments must not contain the sequence "..".
承認が必要であるときに、サーバで、480応答はクライアントから承認を要求するでしょう。 クライアントはAUTHINFO GENERICに入るべきです、続いて、もしあれば固有識別文字名、および議論に入ります。 「固有識別文字と議論は系列を含んではいけない」、」
The server will attempt to engage the server end authenticator, similarly, the client should engage the client end authenticator. The server end authenticator will then initiate authentication using the NNTP sockets (if appropriate for that authentication protocol), using the protocol specified by the authenticator name. These authentication protocols are not included in this document, but are similar in structure to those referenced in RFC 1731 [8] for the IMAP-4 protocol.
サーバは、サーバ終わりの固有識別文字を従事させるのを試みて、同様に、クライアントはクライアント終わりの固有識別文字について約束するべきです。 次に、NNTPソケットを使用することで(その認証プロトコルに適切であるなら)サーバ終わりの固有識別文字は認証を開始するでしょう、固有識別文字名によって指定されたプロトコルを使用して。 これらの認証プロトコルは、本書では含まれていませんが、構造においてIMAP-4プロトコルのためのRFC1731[8]で参照をつけられるそれらと同様です。
If the server returns 501, this means that the authenticator invocation was syntactically incorrect, or that AUTHINFO GENERIC is not supported. The client should retry using the AUTHINFO USER command.
サーバが501を返すなら、これは、固有識別文字実施がシンタクス上不正確であったか、またはAUTHINFO GENERICがサポートされないことを意味します。 クライアントは、AUTHINFO USERコマンドを使用することで再試行するべきです。
If the requested authenticator capability is not found, the server returns the 503 response code.
要求された固有識別文字能力が見つけられないなら、サーバは503応答コードを返します。
If there is some other unspecified server program error, the server returns the 500 response code.
ある他の不特定のサーバプログラムエラーがあれば、サーバは500応答コードを返します。
The authenticators converse using their protocol until complete. If the authentication succeeds, the server authenticator will terminate with a 281, and the client can continue by reissuing the command that prompted the 380. If the authentication fails, the server will respond with a 502.
固有識別文字は、完全になるまでそれらのプロトコルを使用することで話します。 認証が成功すると、サーバ固有識別文字は281で終わるでしょう、そして、クライアントは380をうながしたコマンドを再発行することによって、続くことができます。 認証が失敗すると、サーバは502で反応するでしょう。
Barber Informational [Page 19] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[19ページ]のRFC2980
The client must provide authentication when requested by the server. The server may request authentication at any time. Servers may request authentication more than once during a single session.
サーバによって要求されると、クライアントは認証を提供しなければなりません。サーバはいつでも、認証を要求するかもしれません。 サーバはただ一つのセッションの間の一度より多くの認証を要求するかもしれません。
When the server authenticator completes, it provides to the server (by a mechanism herein undefined) the email address of the user, and potentially what the user is allowed to access. Once authenticated, the server shall generate a Sender: line using the email address provided by the authenticator if it does not match the user-supplied From: line. Additionally, the server should log the event, including the user's authenticated email address (if available). This will provide a means by which subsequent statistics generation can associate newsgroup references with unique entities - not necessarily by name.
サーバ固有識別文字が完成するいつ、サーバに提供するか、(メカニズム、ここに、未定義である、)、ユーザのEメールアドレスと、ユーザは潜在的にアクセサリーに許容される者です。 いったん認証されると、サーバはSenderを生成するものとします: ユーザに供給に合っていないなら固有識別文字によって提供されたEメールアドレスを使用することで立ち並んでください、From: 立ち並んでください。 さらに、サーバはユーザの認証されたEメールアドレス(利用可能であるなら)を含むイベントを登録するべきです。 これはその後の統計世代が必ず名前ではなく、ユニークな実体にニュースグループ参照を関連づけることができる手段を提供するでしょう。
Some implementations make it possible to obtain a list of authentication procedures available by sending the server AUTHINFO GENERIC with no arguments. The server then returns a list of supported mechanisms followed by a period on a line by itself.
いくつかの実装で、議論なしでサーバAUTHINFO GENERICを送ることによって利用可能な認証手順のリストを得るのは可能になります。 サポートしているメカニズムのリスト自体が系列に関する期間までに続いたサーバの当時のリターン。
3.1.3.1 Responses
3.1.3.1 応答
281 Authentication succeeded
480 Authentication required
500 Command not understood
501 Command not supported
502 No permission
503 Program error, function not performed
nnn authenticator-specific protocol.
281 認証の引き継がれた480Authentication必要な500Commandは502いいえ許可503Program誤りであることはサポートされなかった501Commandを理解しないで、また機能はnnnの固有識別文字特有のプロトコルを実行しませんでした。
3.2 DATE
3.2 日付
DATE
日付
The first NNTP working group discussed and proposed a syntax for this command to help clients find out the current time from the server's perspective. At the time this command was discussed (1991-1992), the Network Time Protocol [9] (NTP) was not yet in wide use and there was also some concern that small systems may not be able to make effective use of NTP.
最初のNNTPワーキンググループは、クライアントがサーバの見解から現在の時間を見つけるのを助けるこのコマンドのための構文について議論して、提案しました。 (1991-1992) このコマンドについて議論したとき、Network Timeプロトコル[9](NTP)はまだ広く使用中ではありませんでした、そして、また、小さいシステムがNTPをうまく利用することができないかもしれないという何らかの関心がありました。
This command returns a one-line response code of 111 followed by the GMT date and time on the server in the form YYYYMMDDhhmmss.
このコマンドはフォームYYYYMMDDhhmmssでサーバで111の応答コードがグリニッジ標準時までに続いた1系列日時を返します。
3.2.1 Responses
3.2.1 応答
111 YYYYMMDDhhmmss
111YYYYMMDDhhmmss
Barber Informational [Page 20] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[20ページ]のRFC2980
3.3 The WILDMAT format
3.3 WILDMAT形式
The WILDMAT format was first developed by Rich Salz based on the format used in the UNIX "find" command to articulate file names. It was developed to provide a uniform mechanism for matching patterns in the same manner that the UNIX shell matches filenames. Patterns are implicitly anchored at the beginning and end of each string when testing for a match. There are five pattern matching operations other than a strict one-to-one match between the pattern and the source to be checked for a match. The first is an asterisk (*) to match any sequence of zero or more characters. The second is a question mark (?) to match any single character. The third specifies a specific set of characters. The set is specified as a list of characters, or as a range of characters where the beginning and end of the range are separated by a minus (or dash) character, or as any combination of lists and ranges. The dash can also be included in the set as a character it if is the beginning or end of the set. This set is enclosed in square brackets. The close square bracket (]) may be used in a set if it is the first character in the set. The fourth operation is the same as the logical not of the third operation and is specified the same way as the third with the addition of a caret character (^) at the beginning of the test string just inside the open square bracket. The final operation uses the backslash character to invalidate the special meaning of the a open square bracket ([), the asterisk, backslash or the question mark. Two backslashes in sequence will result in the evaluation of the backslash as a character with no special meaning.
WILDMAT形式は最初に、ファイル名について明確に話すUNIX「見つけ」コマンドに使用される形式に基づいてリッシュ・ザルツによって発生されました。 それは、同じ方法でパターンを合わせるためのUNIXシェルが合っている一定のメカニズムにファイル名を供給するために開発されました。 マッチがないかどうかテストするとき、パターンはそれぞれのストリングの首尾でそれとなく据えつけられます。 マッチがないかどうかチェックされるために、パターンとソースの間には、厳しい1〜1個のマッチ以外の5つのパターン・マッチング操作があります。 1番目はゼロのどんな系列も合わせるアスタリスク(*)であるか以上がキャラクタです。 2番目はどんな単独のキャラクタも合わせる疑問符(?)です。 3番目は特定のキャラクタを指定します。 セットは、キャラクタのリストとして、または、範囲の始めと端が(突進してください)マイナスキャラクタによって切り離されるところか、リストのどんな組み合わせとした1つの範囲のキャラクタとして指定されて、及びます。 また、キャラクタとしてセットにダッシュを含むことができる、それ、セットの始めか端がそうです。 このセットは角括弧で同封されます。 近い角括弧(])はそれがセットで最初のキャラクタであるならセットに使用されるかもしれません。 4番目の操作は、3番目の操作でない論理的と同じであり、テストストリングの始めに3番目として脱字記号キャラクタ(^)の追加でまさしく開いている角括弧で同じように指定されます。 最終的な操作は、a開いている角括弧([)、アスタリスク、バックスラッシュまたは疑問符の特別な意味を無効にするのにバックスラッシュキャラクタを使用します。 2つのバックスラッシュがキャラクタとして特別な意味なしでバックスラッシュの評価を連続してもたらすでしょう。
3.3.1 Examples
3.3.1 例
a. [^]-] -- matches any single character other than a close square
bracket or a minus sign/dash.
a。 [^]-] -- 近い角括弧かマイナス記号/ダッシュ以外のどんな単独のキャラクタも合わせます。
b. *bdc -- matches any string that ends with the string "bdc"
including the string "bdc" (without quotes).
b。 *bdc--ストリング"bdc"がストリング"bdc"(引用文のない)を含んでいて終わるどんなストリングも合わせます。
c. [0-9a-zA-Z] -- matches any single printable alphanumeric ASCII
character.
c。 [0-9 1zA-Z、]、--どんな単独の印刷可能な英数字のASCII文字も合わせます。
d. a??d -- matches any four character string which begins
with a and ends with d.
d. a?d--aで始まって、dで終わるどんな4文字列も合わせます。
Barber Informational [Page 21] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[21ページ]のRFC2980
3.4 Additional Headers
3.4 追加ヘッダー
Many NNTP implementations add headers to Usenet articles when then are POSTed via NNTP. These headers are discussed in this section. None of these headers conflict with those specified in RFC 1036 and should be passed unchanged by Usenet transports conforming to RFC 1036.
その時、NNTPを通してPOSTedがあるとき、多くのNNTP実装がUsenet記事にヘッダーを追加します。 このセクションでこれらのヘッダーについて議論します。 これらのヘッダーのだれもRFC1036で指定されるそれらと闘争して、RFC1036に従うUsenet輸送で変わりがない状態で渡すべきではありません。
3.4.1 NNTP-Posting-Host
3.4.1 NNTP任命ホスト
This line is added to the header of a posted article by the server. The contents of the header is either the IP address or the fully qualified domain name of the client host posting the article. The fully qualified domain name should be determined by doing a reverse lookup in the DNS on the IP address of the client. If the client article contains this line, it is removed by the server before acceptance of the article by the Usenet transport system.
この系列はサーバによって掲示された記事のヘッダーに加えられます。ヘッダーのコンテンツは、記事を掲示しているクライアントホストのIPアドレスか完全修飾ドメイン名のどちらかです。 完全修飾ドメイン名は、クライアントのIPアドレスでDNSで逆のルックアップをすることによって、決定しているべきです。 クライアント記事がこの系列を含んでいるなら、サーバはUsenet輸送システムによる記事の承認の前にそれを取り除きます。
This header provides some idea of the actual host posting the article as opposed to information in the Sender or From lines that may be present in the article. This is not a fool-proof methodology since reverse lookups in the DNS are vulnerable to certain types of spoofing, but such discussions are outside the scope of this document.
このヘッダーは記事で実際のホストが情報と対照的に記事を掲示するというSenderかFromの何らかの考えに存在するかもしれない系列を提供します。 DNSの逆のルックアップが、あるタイプのスプーフィングに被害を受け易いので、これはきわめて簡単な方法論ではありませんが、このドキュメントの範囲の外にそのような議論があります。
3.4.2 X-Newsreader and others
3.4.2 X-ニュースキャスターと他のもの
There are other lines that are added by clients as well. Most of these indicate the type of newsreader software that is posting the article.
また、クライアントによって加えられる他の系列があります。 これらの大部分は記事を掲示しているニュースキャスターソフトウェアのタイプを示します。
4.0 Common Implementation Issues
4.0 一般的な導入問題
Many NNTP implementations do not follow the specifications in RFC 977. In this section, some common implementation issues are summarized.
多くのNNTP実装はRFC977の仕様に従いません。 このセクションで、いくつかの一般的な導入問題がまとめられます。
4.1 The Response to the LIST command
4.1 LISTコマンドへのResponse
RFC 977 says that the fourth field of the "list of valid newsgroups
associated information" returned must be "either 'y' or 'n'
indicating whether posting to this newsgroup is allowed ('y') or
prohibited ('n'). Most implementations simply output the exact
contents of the transport system's active newsgroup list. For more
implementations, the fourth field usually has more values that 'y' or
'n'.
'RFC977が、「有効なニュースグループのリストは情報を関連づけた」返された4番目の分野が「どちらか'yの''('y')がこのニュースグループへの任命に許容されているかどうかを示すか、禁止された('n'であるに違いないと言う、)、」 ほとんどの実装が単に輸送システムのアクティブなニュースグループリストの正確なコンテンツを出力しました。 または、'より多くの実装、通常、分野が持っている4番目に関して、以上がその'y'を評価する、'
Barber Informational [Page 22] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[22ページ]のRFC2980
4.2 The Required Headers in an Article and the POST command
4.2 ArticleのRequired Headersとポストコマンド
RFC 977 notes in section 3.10.1 that articles presented "should include all required header lines." In fact, modern implementations only require From, Subject, and Newsgroups header lines and will supply the rest; further, many implementers believe that it is best for clients to generate as few headers as possible, since clients often do not format other headers correctly.
記事が提示したセクション3.10.1におけるRFC977注意は「すべての必要なヘッダー系列を含むべきです」。 事実上、現代の実装だけが、From、Subject、およびニュースグループヘッダー系列を必要として、残りを供給するでしょう。 さらに、多くのimplementersが、クライアントができるだけわずかなヘッダーしか生成しないのが、最も良いと信じています、クライアントがしばしば正しく他のヘッダーをフォーマットするというわけではないので。
This implementation behavior is consistent with both Bnews and Cnews which would supply missing headers for articles directly submitted to them.
この実装の振舞いは直接提出された記事のための行方不明のヘッダーをそれらに供給するBnewsとCnewsの両方と一致しています。
4.3 Article Numbering
4.3 記事付番
RFC 977 does not directly address the rules concerning articles number. However, the current practice is simple: article numbers are monotonically increasing, articles may disappear, and therefore the high and low water marks returned in a GROUP command should be treated as maximum minima, and minimum maxima, respectively.
RFC977は記事番号に関して直接規則を扱いません。 しかしながら、現在の習慣は簡単です: 記事番号は単調に増加しています、そして、記事は見えなくなるかもしれません、そして、したがって、GROUPコマンドで返された上下のウォーター・マークはそれぞれ最大のminima、および最小のmaximaとして扱われるべきです。
4.4 Availability of commands defined in RFC 977
4.4 RFC977で定義されたコマンドの有用性
Some implementations permit administrators to disable commands defined RFC 977. Some implementations have some set of commands disabled by default. This means that client implementations cannot depend on the availability of the disabled set of commands. This increases the complexity of the client and does not encourage implementors to optimize the implementation of commands that don't perform well.
無効にするコマンドへの実装許可証管理者の中にはRFC977を定義した人もいました。 いくつかの実装で、デフォルトで何らかのセットのコマンドを無効にします。 これは、クライアント実装を障害があるコマンドの有用性に依存できないことを意味します。 これは、クライアントの複雑さを増強して、作成者がよく振る舞わないコマンドの実装を最適化するよう奨励しません。
NEWNEWS is one of the commands frequently disabled.
NEWNEWSは頻繁に無効にされたコマンドの1つです。
4.5 The Distribution header and NEWNEWS
4.5 DistributionヘッダーとNEWNEWS
In section 12.4 of RFC 977, the optional distributions argument is described. This argument, according to RFC 977, would limit the responses to articles that were in newsgroups with prefixes that matched the optional distributions argument.
RFC977のセクション12.4で、任意の配議論は説明されます。 RFC977によると、この議論は任意の配議論に合っていた接頭語で応答をニュースグループにはあった記事に制限するでしょう。
Some implementations implement this by matching the Distributions header in articles to the distribution argument. Others do the match against segments of the newsgroup's name.
いくつかの実現が、記事でDistributionsヘッダーを分配議論に合わせることによって、これを実行します。 他のものはニュースグループの名前のセグメントに対してマッチをします。
This variation is probably best explained by the evolution of the USENET article format. At the time RFC 977 was specified, the newsgroup name defined how the group was distributed throughout USENET. RFC 1036 changed this convention. So, those that are
たぶんUSENET記事形式の発展でこの変化について説明するのは最も良いです。 RFC977が指定されたとき、ニュースグループ名はグループがUSENET中でどう配布されたかを定義しました。 RFC1036はこのコンベンションを変えました。 そのように、そうするそれら
Barber Informational [Page 23] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[23ページ]のRFC2980
strictly implementing RFC 977 would match the newsgroup name prefix against the distribution argument and only display matches. Those that implement against the intent of the command (as modified by the redefinition of the article format)would match the Distributions header against the distribution argument and only display those matches.
厳密にRFC977を実行すると、接頭語というニュースグループ名は分配議論と唯一の表示マッチに対して合っているでしょう。 それがコマンド(記事形式の再定義によって変更されるように)の意図に対して実行するものは、分配議論に対してDistributionsヘッダーを合わせて、それらのマッチを表示するだけでしょう。
5.0 Further Work
5.0 さらなる仕事
With the continued use of NNTP on the Internet, there remains an interest in creating an optimized transport protocol for server-to- server transfers and an optimized client protocol for client-to- server interactions. There is also considerable interest is building better mechanisms to provide audit information on which news groups are being read by which users.
NNTPの継続的な使用がインターネットにあったままで、サーバからサーバへの転送とクライアントからサーバへの相互作用のための最適化されたクライアントプロトコルのために最適化されたトランスポート・プロトコルを作成することへの関心は残っています。 あります、また、相当な興味はニュース・グループがどのユーザによって読まれている監査情報を提供するために、より良いメカニズムを造っています。
An IETF working group has been formed and it is the hope of this author that these issues will be addressed in that forum.
IETFワーキンググループは形成されました、そして、それはこれらの問題がそのフォーラムに記述されるというこの作者の望みです。
6.0 Security Considerations
6.0 セキュリティ問題
The use of the AUTHINFO is optional. This command as documented has a number of security implications. In the original and simple forms, all passwords are passed in plaintext and could be discovered by various forms of network or system surveillance. The AUTHINFO GENERIC command has the potential for the same problems if a mechanism is used that also passes cleartext passwords. RFC 1731 [8] discusses these issues in greater detail.
AUTHINFOの使用は任意です。 記録されるとしてのこのコマンドには、多くのセキュリティ意味があります。 オリジナルの、そして、簡単なフォームでは、すべてのパスワードを平文で通過して、様々な形式のネットワークかシステム監視で発見できるでしょう。 AUTHINFO GENERICコマンドには、また、メカニズムが使用されているならそれがcleartextパスワードを通過することにおける同じ問題の可能性があります。 RFC1731[8]は詳細によりすばらしいこれらの問題について議論します。
7.0 References
7.0の参照箇所
[1] Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC
977, February 1986.
[1] カンターとBとP.ラプスリー、「ネットワークの電子情報を転送するプロトコル」、RFC977、1986年2月。
[2] Limoncelli, Tom, "Read This Before You Write a Newsreader",
http://mars.superlink.net/tal/news-software-authors.html, June,
1996.
[2] Limoncelli、トム、「ニュースキャスターを書く前にこれを読んでください」、 http://mars.superlink.net/tal/news-software-authors.html 、1996年6月。
[3] Horton, M. and R. Adams, "Standard for interchange of USENET
messages", RFC 1036, December 1987.
[3] ホートンとM.とR.アダムス、「USENETメッセージの置き換えの規格」、RFC1036、1987年12月。
[4] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
distribution, UUNET Technologies, Revision 1.10, April, 1992.
[4] ザルツ、リッシュ、INN1.4分配からのwildmat(3)、UUNET Technologies、Revision1.10、1992年4月のManualページ。
[5] Robertson, Rob, "FAQ: Overview database / NOV General
Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
nov.Z, January, 1995.
[5] ロバートソン、ロブ、「FAQ:」 「概観データベース/11月の総合案内」、 ftp://ftp.uu.net/networking/news/nntp/inn/faq- 1995年11月Z、1月。
Barber Informational [Page 24] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[24ページ]のRFC2980
[6] Lea, Iain, "FAQ about the TIN newsreader",
http://www.cs.unca.edu/~davidson/handouts/tinfaq.html
[6] 草地、イアン、「TINニュースキャスターに関するFAQ」、 http://www.cs.unca.edu/~davidson/handouts/tinfaq.html
[7] Kappesser, Peter, "[news.software.readers] trn newsreader FAQ",
2 parts, ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/
software/readers/%5Bnews.software.readers%5D_trn_newsreader
_FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-by
-hierarchy/news/software/readers/%5Bnews.software.readers
%5D_trn_news-reader_FAQ%2C_part_2%3A_Advanced, February, 1995.
[7] 1995年2月、_Kappesser、ピーター、「[news.software.readers]trnニュースキャスターFAQ」、2つの部品、_ ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/ software/readers/%5Bnews.software.readers%5D_trn_ニュースキャスター_FAQ%2のCの部分_1%の3A_Basics、および ftp://rtfm.mit.edu/pub/usenet-by -hierarchy/news/software/readers/%5Bnews.software.readers%5D_trn_ニュースキャスター_FAQ%2のCの部分_2%の3A_Advanced。
[8] Meyers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
December 1994.
[8] メイヤーズ、J.、「IMAP4認証機構」、RFC1731、1994年12月。
[9] Mills, D., "Network Time Protocol (Version 3), Specification,
Implementation and Analysis", RFC 1305, March 1992.
[9] 工場、D.、「ネットワーク時間は(バージョン3)、仕様、実現、および分析について議定書の中で述べる」RFC1305、1992年3月。
8.0 Notes
8.0 注意
DEC is a registered trademark of Compaq Computer Corporation. UNIX is a registered trademark of The Open Group. VMS is a registered trademark of Compaq Computer Corporation.
12月はコンパックコンピュータ社の登録商標です。 UNIXはTheOpenGroupの登録商標です。 VMSはコンパックコンピュータ社の登録商標です。
9.0 Acknowledgments
9.0 承認
The author gratefully acknowledges the comments and additional information provided by the following individuals:
作者は感謝して以下の個人によって提供されたコメントと追加情報を承諾します:
Wayne Davison <davison@armory.com> Chris Lewis <clewis@bnr.ca> Tom Limoncelli <tal@lucent.com> Eric Schnoebelen <eric@egsner.cirr.com> Rich Salz <rsalz@osf.org>
ウェイン Davison <davison@armory.com 、gt;、クリスルイス<clewis@bnr.ca>トム Limoncelli <tal@lucent.com 、gt;、エリックSchnoebelen<eric@egsner.cirr.com>リッシュ Salz <rsalz@osf.org 、gt。
This work was precipitated by the work of various newsreader authors and newsserver authors which includes those listed below:
この仕事は以下に記載されたものを含んでいる様々なニュースキャスターの作者とnewsserver作者の仕事で沈殿しました:
Rick Adams -- Original author of the NNTP extensions to the RN
newsreader and last maintainer of Bnews
Stan Barber -- Original author of the NNTP extensions to the
newsreaders that are part of Bnews.
Geoff Collyer -- Original author of the OVERVIEW database proposal and
one of the original authors of CNEWS
Dan Curry -- Original author of the xvnews newsreader
Wayne Davison -- Author of the first threading extensions to the
RN newsreader (commonly called TRN).
Geoff Huston -- Original author of ANU NEWS
リック・アダムス--RNニュースキャスターへのNNTP拡張子の原作者とBnewsスタン・バーバーの最後の維持装置--Bnewsの一部であるニュースキャスターへのNNTP拡張子の原作者。 ジェフCollyer--OVERVIEWデータベース提案の原作者とダンCurry(xvnewsニュースキャスターのウェイン・デイヴィソンの原作者)が書くRNニュースキャスター(一般的にTRNと呼ばれる)への最初の縫うように通る拡大のCNEWSの原作者のひとり。 ジェフ・ヒューストン--ANU NEWSの原作者
Barber Informational [Page 25] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[25ページ]のRFC2980
Phil Lapsey -- Original author of the UNIX reference
implementation
Iain Lea -- Original maintainer of the TIN newsreader
Chris Lewis -- First known implementor of the AUTHINFO GENERIC
extension
Rich Salz -- Original author of INN
Henry Spencer -- One of the original authors of CNEWS
Kim Storm -- Original author of the NN newsreader
フィルLapsey--UNIX参照実現イアンLeaの原作者--TINニュースキャスターのクリス・ルイスのオリジナルの維持装置--AUTHINFO GENERIC拡張子リッシュ・ザルツの最初の知られている作成者--INNヘンリー・スペンサーの原作者--CNEWSキムStormの原作者のひとり--NNニュースキャスターの原作者
10.0 Author's Address
10.0 作者のアドレス
Stan Barber P.O. Box 300481 Houston, Texas, 77230
ヒューストン、スタンバーバーP.O. Box300481テキサス 77230
EMail: sob@academ.com
メール: sob@academ.com
Barber Informational [Page 26] RFC 2980 Common NNTP Extensions October 2000
NNTP拡大2000年10月に一般的な床屋情報[26ページ]のRFC2980
11.0 Full Copyright Statement
11.0 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Barber Informational [Page 27]
バーバーInformationalです。[27ページ]
一覧
スポンサーリンク
