Network Working Group J. Vinocur
Request for Comments: 4644 Cornell University
Updates: 2980 K. Murchison
Category: Standards Track Carnegie Mellon University
October 2006
Network News Transfer Protocol (NNTP) Extension for Streaming Feeds
ネットワークニュース転送プロトコル（NNTP）ストリーミングフィードのための拡張
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo defines an extension to the Network News Transfer Protocol (NNTP) to provide asynchronous (otherwise known as "streaming") transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency.
このメモは、記事の（そうでない場合は、「ストリーミング」として知られている）非同期転送を提供するために、ネットワークニュース転送プロトコル（NNTP）への拡張を定義します。これは、サーバがはるかに大きい効率で他のサーバーに記事を転送することができます。
This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command.
このドキュメントの更新とCHECKを形式化し、TAKETHISコマンドは、RFC 2980で指定されたとのMODE STREAMコマンドを非難します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in this Document ..........................2
2. The STREAMING Extension .........................................3
2.1. Streaming Article Transfer .................................3
2.2. Advertising the STREAMING Extension ........................4
2.3. MODE STREAM Command ........................................5
2.3.1. Usage ...............................................5
2.3.2. Description .........................................5
2.3.3. Examples ............................................5
2.4. CHECK Command ..............................................6
2.4.1. Usage ...............................................6
2.4.2. Description .........................................6
2.4.3. Examples ............................................6
2.5. TAKETHIS Command ...........................................7
2.5.1. Usage ...............................................7
2.5.2. Description .........................................7
2.5.3. Examples ............................................8
3. Augmented BNF Syntax for the STREAMING Extension ................9
3.1. Commands ...................................................9
3.2. Command Datastream .........................................9
3.3. Responses .................................................10
3.4. Capability Entries ........................................10
4. Summary of Response Codes ......................................10
5. Security Considerations ........................................11
6. IANA Considerations ............................................11
7. Acknowledgements ...............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................12
According to the NNTP specification [NNTP], a peer uses the IHAVE command to query whether a server wants a particular article. Because the IHAVE command cannot be pipelined, the need to stop and wait for the remote end's response greatly restricts the throughput that can be achieved.
NNTP仕様[NNTP]によると、ピアは、サーバが特定の記事を望んでいるかどうかを照会するIHAVEコマンドを使用しています。 IHAVEコマンドをパイプライン化することができないので、停止して、リモートエンドの応答を待つ必要は大幅に達成することができ、スループットを制限します。
The ad-hoc CHECK and TAKETHIS commands, originally documented in [NNTP-COMMON], provide an alternative method of peer-to-peer article transfer that permits a more effective use of network bandwidth. Due to their proven usefulness and wide deployment, they are formalized in this specification.
アドホックCHECK元々[NNTP-COMMON]に記載のコマンドは、ネットワーク帯域幅のより有効な使用を可能にするピア・ツー・ピア物品移送の代替方法を提供するTAKETHIS。それらの実績のある有用性と広い展開に、彼らはこの仕様で正式にされています。
The ad-hoc MODE STREAM command, also documented in [NNTP-COMMON], is deprecated by this specification, but due to its ubiquity is documented here for backwards compatibility.
また、[NNTP-COMMON]で文書アドホックモードのSTREAMコマンドは、この仕様で推奨されていません、しかし、その普遍性への後方互換性のために、ここで説明されています。
The notational conventions used in this document are the same as those in [NNTP] and any term not defined in this document has the same meaning as in that one.
本書で使用される表記規則は、[NNTP]と同じであり、この文書で定義されていない任意の用語は、1つの場合と同じ意味を有します。
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
キーワード「REQUIRED」、「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」RFCsにおける使用のためのキーワード」で説明したように、このドキュメントの「MAY」、および「OPTIONAL」は解釈されるべきです要件レベル」[KEYWORDS]を示すために。
This document assumes you familiarity with NNTP [NNTP]. In general, the connections described below are from one peer to another, but we will continue to use "client" to mean the initiator of the NNTP connection, and "server" to mean the other endpoint.
この文書では、NNTP [NNTP]でお馴染みの前提としています。一般的には、下記の接続は1つのピアから別のものにしているが、我々は、他のエンドポイントを意味するNNTP接続のイニシエータ、および「サーバー」を意味する「クライアント」を使用していきます。
In the examples, commands from the client are indicated with [C], and responses from the server are indicated with [S].
実施例では、クライアントからのコマンドは、[C]で示され、そしてサーバからの応答は、[S]で示されています。
This extension provides three new commands: MODE STREAM, CHECK, and TAKETHIS. The capability label for this extension is STREAMING.
MODEのSTREAM、CHECK、およびTAKETHIS：この拡張モジュールは、3の新しいコマンドを提供します。この拡張のための能力ラベルは、ストリーミングです。
The STREAMING extension provides the same functionality as the IHAVE command ([NNTP] section 6.3.2) but splits the query and transfer functionality into the CHECK and TAKETHIS commands respectively. This allows the CHECK and TAKETHIS commands to be pipelined ([NNTP] section 3.5) and provides for "streaming" article transfer.
STREAMING拡張はIHAVEコマンド（[NNTP]セクション6.3.2）と同じ機能を提供するが、CHECKにクエリと転送機能を分割しTAKETHISそれぞれ指示します。これは、CHECKを可能とTAKETHISは（[NNTP]セクション3.5）パイプライン化する命令と、「ストリーミング」物品移載を提供します。
A streaming client will often pipeline many CHECK commands and use the responses to construct a list of articles to be sent by a pipelined sequence of TAKETHIS commands, thus increasing the fraction of time spent transferring articles. The CHECK and TAKETHIS commands utilize distinct response codes so that these commands can be intermingled in a pipeline and the response to any single command can be definitively identified by the client.
ストリーミングクライアントは、多くの場合、パイプライン、多くのCHECKコマンドは、このように記事を転送費やした時間の割合を増やす、TAKETHISのパイプライン化された一連のコマンドが送信する記事のリストを構築するための応答を使用しますと。これらのコマンドは、パイプライン内に混在することができ、任意の単一のコマンドに対する応答が決定的にクライアントによって同定することができるようにCHECKとTAKETHISコマンドが異なる応答コードを利用します。
The client MAY send articles via TAKETHIS without first querying the server with CHECK. The client SHOULD NOT send every article in this fashion unless explicitly configured to do so by the site administrator based on out-of-band information. However, the client MAY use an adaptive strategy where it initially sends CHECK commands for all articles, but switches to using TAKETHIS without CHECK if most articles are being accepted (over 95% acceptance might be a reasonable metric in some configurations). If the client uses such a strategy, it SHOULD also switch back to using CHECK on all articles if the acceptance rate ever falls much below the threshold.
クライアントは、最初にCHECKしてサーバに問い合わせることなく、TAKETHISを経由して記事を送信することができます。明示的にアウトオブバンド情報に基づいて、サイト管理者がそうするように構成されていない限り、クライアントはこの方法ですべての記事を送るべきではありません。ただし、クライアントは、それが最初にすべての記事のためのチェックコマンドを送信しますが、ほとんどの記事が受け入れられている場合（95％以上の受け入れは、いくつかの構成では、合理的なメトリックであるかもしれない）CHECKなしTAKETHISを使用するように切り替えた適応戦略を使用するかもしれません。クライアントは、このような戦略を使用している場合は合格率がこれまでに多くの閾値を下回った場合、それはまた、すべての記事のチェックを使用してに切り替えるべきです。
A server supporting the streaming commands described in this document will advertise the "STREAMING" capability label in response to the CAPABILITIES command ([NNTP] section 5.2). The server MUST continue to advertise this capability after a client has issued the MODE STREAM command. This capability MAY be advertised both before and after any use of the MODE READER command ([NNTP] section 5.3), with the same semantics.
このドキュメントで説明ストリーミングコマンドをサポートするサーバは、capabilitiesコマンド（[NNTP]セクション5.2）に対応して「ストリーミング」機能ラベルをアドバタイズします。クライアントは、MODEのSTREAMコマンドを発行した後、サーバーは、この機能をアドバタイズし続けなければなりません。この機能は、同じ意味で、MODEリーダコマンド（[NNTP]セクション5.3）の使用前と後の両方でアドバタイズされるかもしれません。
Example of a client using CAPABILITIES and MODE STREAM on a mode-switching server:
モード切替サーバー上の機能とMODEのSTREAMを使用して、クライアントの例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] MODE-READER [S] IHAVE [S] LIST ACTIVE [S] STREAMING [S] . [C] MODE STREAM [S] 203 Streaming permitted [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] MODE-READER [S] IHAVE [S] LIST ACTIVE [S] STREAMING [S] . [C] MODE READER [S] 200 Posting allowed [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] POST [S] LIST ACTIVE NEWSGROUPS HEADERS [S] HDR [S] .
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] MODE-READER [S] IHAVE [S] LIST ACTIVE [S] STREAMING [S]。 [S] VERSION 2 [S] MODE-READER [S] IHAVE [S] LIST ACTIVE [S] STREAMING [S]：[C] MODEストリームは、[S] 203ストリーミング[C] CAPABILITIES [S] 101の能力リストを可能にしました。 [C] MODEリーダ[S] 200転記許可[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] POST [S] LIST ACTIVEニュースグループHEADERS [S] HDR [S]。
Historically this command was used by a client to discover if a server supported the CHECK and TAKETHIS commands. This command is deprecated in favor of the CAPABILITIES discovery command and is only provided here for compatibility with legacy implementations [NNTP-COMMON] of these transport commands.
歴史的に、このコマンドは、サーバーがCHECKとTAKETHISコマンドをサポートしている場合発見するためにクライアントによって使用されました。このコマンドは、ケーパビリティ発見コマンドの賛成で廃止され、これらのみのトランスポートコマンドのレガシー実装[NNTP-COMMON]との互換性のために、ここで提供されます。
New clients SHOULD use the CAPABILITIES command to check a server for support of the STREAMING extension but MAY use the MODE STREAM command for backwards compatibility with legacy servers that don't support the CAPABILITIES discovery command. Servers MUST accept the MODE STREAM command for backwards compatibility with legacy clients that don't use the CAPABILITIES discovery command.
新しいクライアントは、ストリーミングの拡張をサポートするためのサーバーをチェックするcapabilitiesコマンドを使用すべきであるが、能力探索コマンドをサポートしていない従来のサーバーとの後方互換性のためのMODE STREAMコマンドを使用するかもしれません。サーバーは能力探索コマンドを使用していないレガシークライアントとの下位互換性のためのMODE STREAMコマンドを受け入れなければなりません。
NOTE: This command may be removed from a future version of this specification, therefore clients are urged to transition to the CAPABILITIES command wherever possible.
注：このコマンドは、クライアントは、可能な限り機能がコマンドへの移行を促しているので、この仕様の将来のバージョンから除去することができます。
Syntax MODE STREAM
構文MODEのSTREAM
Responses 203 Streaming permitted
203ストリーミングが許可の回答
If a server supports this extension, it MUST return a 203 response to the MODE STREAM command (or 501 if an argument is given). The MODE STREAM command MUST NOT affect the server state in any way (that is, it is not a mode change despite the name), therefore this command MAY be pipelined. A server MUST NOT require that the MODE STREAM command be issued by the client before accepting the CHECK or TAKETHIS commands.
サーバはこの拡張機能をサポートしている場合（引数が指定されている場合または501）、モードSTREAMコマンドへの203応答を返さなければなりません。 MODEのSTREAMコマンドは（つまり、それは名前にもかかわらず、モード変更ではありません）どのような方法で、サーバーの状態に影響してはいけません、そのため、このコマンドは、パイプライン化してもよいです。サーバーは、MODEのSTREAMコマンドはCHECKまたはTAKETHISコマンドを受け入れる前に、クライアントによって発行されることを要求してはなりません。
Example of a client checking the ability to stream articles on a server which does not support this extension:
この拡張機能をサポートしていないサーバー上の記事をストリーミングする能力をチェックするクライアントの例：
[C] MODE STREAM [S] 501 Unknown MODE variant
[C]モードSTREAM [S] 501不明MODE変異
Example of a client checking the ability to stream articles on a server which supports this extension:
この拡張をサポートするサーバ上の記事をストリーミングする能力をチェックするクライアントの例：
[C] MODE STREAM [S] 203 Streaming permitted
[C]モードSTREAM [S] 203ストリーミング許可
Syntax CHECK message-id
構文チェックメッセージID
Responses 238 message-id Send article to be transferred 431 message-id Transfer not possible; try again later 438 message-id Article not wanted
応答238メッセージIDは不可能431メッセージIDの転送を転送する記事を送信します。後でもう一度たかっない438メッセージIDの記事を試します
Parameters message-id = Article message-id
パラメータメッセージID =記事のメッセージID
The first parameter of the 238, 431, and 438 responses MUST be the message-id provided by the client as the parameter to CHECK.
238、431、及び438の応答の最初のパラメータがチェックするために、パラメータとしてクライアントによって提供されるメッセージIDでなければなりません。
The CHECK command informs the server that the client has an article with the specified message-id. If the server desires a copy of that article, a 238 response MUST be returned, indicating that the client may send the article using the TAKETHIS command. If the server does not want the article (if, for example, the server already has a copy of it), a 438 response MUST be returned, indicating that the article is not wanted. Finally, if the article isn't wanted immediately but the client should retry later if possible (if, for example, another client has offered to send the same article to the server), a 431 response MUST be returned.
CHECKコマンドは、クライアントが指定したメッセージIDとの記事があり、サーバーに通知します。サーバーがその記事のコピーを希望する場合は、238応答は、クライアントがTAKETHISコマンドを使用して記事を送信する可能性があることを示す、返さなければなりません。サーバは（例えば、サーバはすでにそれのコピーを持っている場合）の記事を望んでいない場合は、438応答は、物品が欲しかっされていないことを示す、返さなければなりません。記事がすぐに望んでいたのではなく、可能な場合（例えば、別のクライアントがサーバに同じ記事を送信するために提供してきました、場合）クライアントは、後で再試行する必要がある場合は最後に、431応答が返されなければなりません。
NOTE: The responses to CHECK are advisory; the server MUST NOT rely on the client to behave as requested by these responses.
注：チェックするために応答が助言しています。サーバーは、これらの応答によって要求されるように動作するようにクライアントに依存してはなりません。
Example of a client checking whether the server would like a set of articles and getting a mixture of responses:
クライアントは、サーバが記事のセットを希望するかどうかをチェックし、応答の混合物を取得する例：
[C] CHECK <i.am.an.article.you.will.want@example.com> [S] 238 <i.am.an.article.you.will.want@example.com> [C] CHECK <i.am.an.article.you.have@example.com> [S] 438 <i.am.an.article.you.have@example.com> [C] CHECK <i.am.an.article.you.defer@example.com> [S] 431 <i.am.an.article.you.defer@example.com>
[C]のチェック<i.am.an.article.you.will.want@example.com> [S] 238 <i.am.an.article.you.will.want@example.com> [C] CHECK <i.am.an.article.you.have@example.com> [S] 438 <i.am.an.article.you.have@example.com> [C]のチェック<i.am.an.article .you.defer @ example.com> [S] 431 <i.am.an.article.you.defer@example.com>
Example of pipelining the CHECK commands in the previous example:
前の例でCHECKコマンドをパイプラインの例：
[C] CHECK <i.am.an.article.you.will.want@example.com> [C] CHECK <i.am.an.article.you.have@example.com> [C] CHECK <i.am.an.article.you.defer@example.com> [S] 238 <i.am.an.article.you.will.want@example.com> [S] 438 <i.am.an.article.you.have@example.com> [S] 431 <i.am.an.article.you.defer@example.com>
[C]のチェック<i.am.an.article.you.will.want@example.com> [C]のチェック<i.am.an.article.you.have@example.com> [C]のチェック<私.am.an.article.you.defer @ example.com> [S] 238 <i.am.an.article.you.will.want@example.com> [S] 438 <i.am.an.article .you.have @ example.com> [S] 431 <i.am.an.article.you.defer@example.com>
A client MUST NOT use this command unless the server advertises the STREAMING capability or returns a 203 response to the MODE STREAM command.
サーバはストリーミング機能をアドバタイズまたはMODEのSTREAMコマンドへの203応答を返さない限り、クライアントは、このコマンドを使用してはなりません。
Syntax TAKETHIS message-id
構文TAKETHISのメッセージID
Responses 239 message-id Article transferred OK 439 message-id Transfer rejected; do not retry
応答239メッセージID条が拒否OK 439メッセージIDの転送を転送します。再試行しないでください
Parameters message-id = Article message-id
パラメータメッセージID =記事のメッセージID
The first parameter of the 239 and 439 responses MUST be the message-id provided by the client as the parameter to TAKETHIS.
239と439応答の最初のパラメータはTAKETHISに対するパラメータとしてクライアントによって提供されるメッセージIDでなければなりません。
The TAKETHIS command is used to send an article with the specified message-id to the server. The article is sent immediately following the CRLF at the end of the TAKETHIS command line. The client MUST send the entire article, including headers and body, to the server as a multi-line data block ([NNTP] section 3.1.1). Thus, a single dot (".") on a line indicates the end of the text, and lines starting with a dot in the original text have that dot doubled during transmission. The server MUST return either a 239 response, indicating that the article was successfully transferred, or a 439 response, indicating that the article was rejected. If the server encounters a temporary error that prevents it from processing the article but does not want to reject the article, it MUST reply with a 400 response to the client and close the connection.
TAKETHISコマンドは、サーバに、指定されたメッセージIDとの記事を送信するために使用されます。記事は、TAKETHISコマンドラインの末尾にCRLFの直後に送信されます。クライアントは、複数行のデータブロック（[NNTP]セクション3.1.1）としてサーバーに、ヘッダと本体を含む全体の記事を送信しなければなりません。このように、ライン上の単一のドット（「」）テキストの終わりを示しており、元のテキストのドットで始まる行は、伝送中にそのドットを倍増しています。サーバは、物品が正常に記事が拒否されたことを示す、転送、または439応答されたことを示す、239応答のどちらかを返さなければなりません。サーバは、物品を処理するのを防止するが、記事を拒否することを望んでいない一時的なエラーが発生した場合、それはクライアントに400応答で応答し、接続を閉じる必要があります。
This function differs from the POST command in that it is intended for use in transferring already-posted articles between hosts. It
この機能は、それがホスト間で既に掲載記事を転送する際に使用することを意図されている点でPOSTコマンドとは異なります。それ
SHOULD NOT be used when the client is a personal news-reading program, since use of this command indicates that the article has already been posted at another site and is simply being forwarded from another host. However, despite this, the server MAY elect not to post or forward the article if, after further examination of the article, it deems it inappropriate to do so. Reasons for such subsequent rejection of an article may include problems such as inappropriate newsgroups or distributions, disk space limitations, article lengths, garbled headers, and the like. These are typically restrictions enforced by the server host's news software and not necessarily by the NNTP server itself.
このコマンドを使用すると、記事はすでに別のサイトに掲載されており、単に別のホストから転送されていることを示しているので、クライアントは、個人のニュース読み取りプログラムであるときに使用されるべきではありません。しかし、それにもかかわらず、サーバーは、物品の更なる検討の後、それはそうすることが不適切と判断、場合記事を投稿したり、転送しないことを選択できます。物品のようなその後の拒絶理由は、不適切なニュースグループまたは配布、ディスクスペースの制限、物品の長さ、文字化けヘッダなどの問題を含んでいてもよいです。これらは、典型的には、サーバホストのニュースソフトウェアによって必ずしもNNTPサーバ自身によって強制制限があります。
The client SHOULD NOT assume that the article has been successfully transferred unless it receives an affirmative response from the server. A lack of response (such as a dropped network connection or a network timeout) or a 400 response SHOULD be treated as a temporary failure and cause the transfer to be tried again later if possible.
クライアントは、サーバからの肯定応答を受信しない限り、記事は正常に転送されたことを仮定するべきではありません。 （例えばドロップネットワーク接続またはネットワークタイムアウトなど）応答または400応答の欠如は、一時的な障害として扱われ、可能であれば転送は後で再試行させることべきです。
Because some news server software may not immediately be able to determine whether an article is suitable for posting or forwarding, an NNTP server MAY acknowledge the successful transfer of the article (with a 239 response) but later silently discard it.
いくつかのニュースサーバーソフトウェアは、すぐに記事が掲載または転送に適しているかどうかを決定することができない場合がありますので、NNTPサーバは（239応答で）、物品の成功転送を認めたが、後に静かにそれを捨てるかもしれ。
Example of streaming two articles to another site (the first article is accepted and the second is rejected):
（最初の記事が受け入れられ、第二が拒否された）他のサイトへの2件の記事をストリーミングの例：
[C] TAKETHIS <i.am.an.article.you.will.want@example.com> [C] Path: pathost!demo!somewhere!not-for-mail [C] From: "Demo User" <nobody@example.com> [C] Newsgroups: misc.test [C] Subject: I am just a test article [C] Date: 6 Oct 1998 04:38:40 -0500 [C] Organization: An Example Com, San Jose, CA [C] Message-ID: <i.am.an.article.you.will.want@example.com> [C] [C] This is just a test article. [C] . [C] TAKETHIS <i.am.an.article.you.have@example.com> [C] Path: pathost!demo!somewhere!not-for-mail [C] From: "Demo User" <nobody@example.com> [C] Newsgroups: misc.test [C] Subject: I am just a test article [C] Date: 6 Oct 1998 04:38:40 -0500 [C] Organization: An Example Com, San Jose, CA [C] Message-ID: <i.am.an.article.you.have@example.com> [C]
[C] TAKETHISは<i.am.an.article.you.will.want@example.com> [C]のパス：！！！pathostデモどこかにない-用メール[C]から： "デモ・ユーザー" <誰も@ example.com> [C]ニュースグループ：misc.test [C]件名：1998年10月6日午前4時38分40秒-0500 [C]組織：例：COM、サンノゼ私は、テストの記事[C]日午前、CA [C]メッセージID：<i.am.an.article.you.will.want@example.com> [C] [C]これは単なる試験物品です。 [C]。 [C] TAKETHIS <i.am.an.article.you.have@example.com> [C]のパス：！！！pathostデモどこかにない-用メール[C]から： "デモ・ユーザー" <例@誰も.COM> [C]ニュースグループ：misc.test [C]件名：私はちょうどテストの記事[C]日午前：1998年10月6日午前4時38分40秒-0500 [C]組織：例コム、サンノゼ、CA [C]メッセージID：<i.am.an.article.you.have@example.com> [C]
[C] This is just a test article. [C] . [S] 239 <i.am.an.article.you.will.want@example.com> [S] 439 <i.am.an.article.you.have@example.com>
[C]これは単なる試験物品です。 [C]。 [S] 239 <i.am.an.article.you.will.want@example.com> [S] 439 <i.am.an.article.you.have@example.com>
Example of sending an article to a site where the transfer fails:
転送が失敗したサイトに記事を送信する例：
[C] TAKETHIS <i.am.an.article.you.will.want@example.com> [C] Path: pathost!demo!somewhere!not-for-mail [C] From: "Demo User" <nobody@example.com> [C] Newsgroups: misc.test [C] Subject: I am just a test article [C] Date: 6 Oct 1998 04:38:40 -0500 [C] Organization: An Example Com, San Jose, CA [C] Message-ID: <i.am.an.article.you.will.want@example.com> [C] [C] This is just a test article. [C] . [S] 400 Service temporarily unavailable [Server closes connection.]
[C] TAKETHISは<i.am.an.article.you.will.want@example.com> [C]のパス：！！！pathostデモどこかにない-用メール[C]から： "デモ・ユーザー" <誰も@ example.com> [C]ニュースグループ：misc.test [C]件名：1998年10月6日午前4時38分40秒-0500 [C]組織：例：COM、サンノゼ私は、テストの記事[C]日午前、CA [C]メッセージID：<i.am.an.article.you.will.want@example.com> [C] [C]これは単なる試験物品です。 [C]。 [S] 400一時的に利用できないサービス[サーバーが接続を閉じます。]
This section describes the formal syntax of the STREAMING extension using ABNF [ABNF]. It extends the syntax in section 9 of [NNTP], and non-terminals not defined in this document are defined there. The [NNTP] ABNF should be imported first before attempting to validate these rules.
このセクションでは、ABNF [ABNF]を使用してストリーミング延長の正式な構文について説明します。これは、[NNTP]のセクション9で構文を拡張し、この文書で定義されていない非端末はそこに定義されています。 [NNTP] ABNFはこれらの規則を検証しようとする前に、最初にインポートする必要があります。
This syntax extends the non-terminal "command", which represents an NNTP command.
この構文は、NNTPコマンドを表す非終端「コマンド」、延びています。
command =/ check-command / mode-stream-command / takethis-command
コマンド= /チェックコマンド/モード・ストリーム・コマンド/ TAKETHISコマンド
check-command = "CHECK" WS message-id mode-stream-command = "MODE" WS "STREAM" takethis-command = "TAKETHIS" WS message-id
チェックコマンド= WSメッセージIDモードストリームコマンドを "チェック" = "MODE" WS "STREAM" TAKETHISコマンド= "TAKETHIS" WSのメッセージID
This syntax extends the non-terminal "command-datastream", which represents the further material sent by the client in the case of streaming commands.
この構文は、ストリーミングコマンドの場合、クライアントから送信され、さらに材料を表し非終端「コマンド・データ・ストリーム」を、拡張します。
command-datastream =/ takethis-datastream
コマンドデータストリーム= / TAKETHIS、データストリーム
takethis-datastream = encoded-article
TAKETHIS-データストリーム=エンコード-記事
This syntax extends the non-terminal "initial-response-content", which represents an initial response line sent by the server.
この構文は、サーバによって送信された初期応答ラインを表す非終端「初期応答内容」、延びています。
initial-response-content =/ response-238-content / response-239-content / response-431-content / response-438-content / response-439-content
初期応答含量= /応答238コンテンツ/応答239コンテンツ/応答431コンテンツ/応答438コンテンツ/応答439コンテンツ
response-238-content = "238" SP message-id response-239-content = "239" SP message-id response-431-content = "431" SP message-id response-438-content = "438" SP message-id response-439-content = "439" SP message-id
= "238" SPのメッセージID応答-239-コンテンツ= "239" SPのメッセージID応答-431-コンテンツ= "431" SPのメッセージID応答-438-コンテンツ= "438" SPメッセージ応答238コンテンツ-id応答-439-コンテンツ= "439" SPのメッセージID
This syntax extends the non-terminal "capability-entry", which represents a capability that may be advertised by the server.
この構文は、サーバによって通知することができる能力を表す非末端「機能エントリ」を、延びています。
capability-entry =/ streaming-capability
機能-エントリ= /ストリーミング機能
streaming-capability = "STREAMING"
ストリーミング機能=「ストリーミング」
This section contains a list of each new response code defined in this document and indicates whether it is multi-line, which commands can generate it, what arguments it has, and what its meaning is.
このセクションでは、この文書で定義されたそれぞれの新しい応答コードのリストが含まれ、それが持っているものの引数、それはそれを生成できるコマンドを複数行、であるかどうかを示す、と何の意味があります。
Response code 203 Generated by: MODE STREAM Meaning: streaming permitted.
MODEのSTREAM意味：：によって生成された応答コード203許可ストリーミング。
Response code 238 Generated by: CHECK 1 argument: message-id Meaning: send article to be transferred.
生成された応答コード238：メッセージIDの意味：：転送されるように記事を送信する1引数を確認してください。
Response code 239 Generated by: TAKETHIS 1 argument: message-id Meaning: article transferred OK.
TAKETHIS 1つの引数：メッセージID意味：記事がOK転写によって生成された応答コード239。
Response code 431 Generated by: CHECK 1 argument: message-id Meaning: transfer not possible; try again later.
生成された応答コード431：メッセージIDの意味：1つの引数チェック転送可能ではないと、あとでもう一度試してみてください。
Response code 438 Generated by: CHECK 1 argument: message-id Meaning: article not wanted.
生成された応答コード438：メッセージIDの意味：：1引数をCHECK記事たかっありません。
Response code 439 Generated by: TAKETHIS 1 argument: message-id Meaning: transfer rejected; do not retry.
TAKETHIS 1引数：メッセージID意味：によって生成された応答コード439の転送が拒否。再試行しません。
No new security considerations are introduced by this extension, beyond those already described in the core specification [NNTP].
新たなセキュリティ上の考慮事項は、すでにコア仕様[NNTP]に記載されているものを超えて、この拡張によって導入されていません。
This section gives a formal definition of the STREAMING extension as required by Section 3.3.3 of [NNTP] for the IANA registry.
IANAレジストリのために[NNTP]のセクション3.3.3で必要とされるこのセクションでは、ストリーミングの拡張子の正式な定義を与えます。
o The STREAMING extension provides for streaming transfer of articles.
Oストリーミング拡張子は記事のストリーミング転送を提供します。
o The capability label for this extension is "STREAMING".
Oこの拡張のための能力ラベルは、「ストリーミング」です。
o The capability label has no arguments.
O機能のラベルには引数がありません。
o The extension defines three new commands, MODE STREAM, CHECK, and TAKETHIS, whose behavior, arguments, and responses are defined in Sections 2.3, 2.4, and 2.5 respectively.
O拡張3つの新しいコマンド、モードSTREAM、CHECK、およびTAKETHIS、その挙動、引数を定義し、そして応答は、セクション2.3、2.4で定義され、それぞれ2.5。
o The extension does not associate any new responses with pre-existing NNTP commands.
O拡張モジュールは、既存のNNTPコマンドで、新しい応答を関連付けることはありません。
o The extension does not affect the behavior of a server or client other than via the new commands.
Oの拡張は、新しいコマンド経由以外のサーバやクライアントの動作には影響を与えません。
o The extension does not affect the maximum length of commands or initial response lines.
Oの拡張は、コマンドや初期応答行の最大長さに影響を与えることはありません。
o The extension does not alter pipelining, and the MODE STREAM, CHECK, and TAKETHIS commands can be pipelined.
O拡張モジュールは、パイプラインを変更していない、とMODEストリームは、CHECK、およびTAKETHISコマンドをパイプライン化することができます。
o Use of this extension does not alter the capabilities list.
Oこの拡張機能を使用すると、機能のリストは変更されません。
o The extension does not cause any pre-existing command to produce a 401, 480, or 483 response.
O拡張は、任意の既存のコマンド401、480、または483応答を生成させません。
o Use of the MODE READER command on a mode-switching server may disable this extension.
Oモード切替サーバーのMODE READERコマンドを使用すると、この拡張機能を無効にすることができます。
o Published Specification: This document.
O発行仕様：このドキュメント。
o Contact for Further Information: Authors of this document.
詳しい情報についてはO接点：この文書の著者。
o Change Controller: IESG <iesg@ietf.org>.
Oの変更コントローラ：IESG <iesg@ietf.org>。
This document is based heavily on the relevant sections of RFC 2980 [NNTP-COMMON], by Stan Barber.
この文書は、スタン・バーバーによって、RFC 2980の関連セクション[NNTP-COMMON]に大きく基づいています。
Special acknowledgement also goes to Russ Allbery, Clive Feather, Andrew Gierth, and others who commented privately on intermediate revisions of this document, as well as the members of the IETF NNTP Working Group for continual (yet sporadic) insight in discussion.
特別承認もラスAllbery、クライヴフェザー、アンドリューGierth、中間、この文書の改訂版だけでなく、議論の継続的な（まだ散発的）な洞察力のためのIETF NNTPワーキンググループのメンバーに個人的コメント、他に行きます。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[NNTP]フェザー、C.、 "ネットワークニュース転送プロトコル（NNTP）"、RFC 3977、2006年10月。
[NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[NNTP-COMMON]理容室、S.、 "共通NNTP拡張機能"、RFC 2980、2000年10月。
Authors' Addresses
著者のアドレス
Jeffrey M. Vinocur Department of Computer Science Upson Hall Cornell University Ithaca, NY 14853
コンピュータサイエンスアップソンホールコーネル大学イサカ、NY 14853のジェフリーM. Vinocur部門
EMail: vinocur@cs.cornell.edu
メールアドレス：vinocur@cs.cornell.edu
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 USA
ケネス・マーチソンカーネギーメロン大学5000フォーブス・アベニューCyertホール285ピッツバーグ、PA 15213 USA
EMail: murch@andrew.cmu.edu
メールアドレス：murch@andrew.cmu.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。