RFC4644 日本語訳
4644 Network News Transfer Protocol (NNTP) Extension for StreamingFeeds. J. Vinocur, K. Murchison. October 2006. (Format: TXT=26439 bytes) (Updates RFC2980) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Vinocur
Request for Comments: 4644 Cornell University
Updates: 2980 K. Murchison
Category: Standards Track Carnegie Mellon University
October 2006
Vinocurがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4644のコーネル大学アップデート: 2980年のK.マーチソンカテゴリ: 標準化過程カーネギーメロン大学2006年10月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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はRFC2980で指定されていた状態で命令して、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
1. 序論…2 1.1. このDocumentのコンベンションUsed…2 2. ストリーミングの拡大…3 2.1. 記事を流して、移してください…3 2.2. ストリーミングの拡大の広告を出します…4 2.3. モードストリームコマンド…5 2.3.1. 用法…5 2.3.2. 記述…5 2.3.3. 例…5 2.4. コマンドをチェックしてください…6 2.4.1. 用法…6 2.4.2. 記述…6 2.4.3. 例…6 2.5. TAKETHISは命令します…7
Vinocur & Murchison Standards Track [Page 1] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[1ページ]RFC4644NNTP拡張子
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
2.5.1. 用法…7 2.5.2. 記述…7 2.5.3. 例…8 3. ストリーミングの拡大のためのBNF構文を増大させます…9 3.1. コマンド…9 3.2. Datastreamを命令してください…9 3.3. 応答…10 3.4. 能力エントリー…10 4. 応答コードの概要…10 5. セキュリティ問題…11 6. IANA問題…11 7. 承認…12 8. 参照…12 8.1. 標準の参照…12 8.2. 有益な参照…12
1. Introduction
1. 序論
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コマンドをpipelinedされることができないので、リモートエンドの応答を止めて、待つ必要性は達成できるスループットを大いに制限します。
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.
元々[NNTP-COMMON]に記録された臨時のCHECKと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]に記録された臨時のMODE STREAMコマンドは、この仕様で推奨しないのですが、偏在のため遅れている互換性のためにここに記録されます。
1.1. Conventions Used in this Document
1.1. このDocumentのコンベンションUsed
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]のそれらと同じです、そして、本書では定義されなかったどんな用語もそのように意味しながら、同じくらい持っています。
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].
“MUST"、「必須NOT」がキーワードが、「必要でした」、“SHOULD"、「」、「5月」、このドキュメントで「任意」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で説明されるように解釈されることであるべきです。
Vinocur & Murchison Standards Track [Page 2] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[2ページ]RFC4644NNTP拡張子
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]で示されます。
2. The STREAMING Extension
2. ストリーミングの拡大
This extension provides three new commands: MODE STREAM, CHECK, and TAKETHIS. The capability label for this extension is STREAMING.
この拡大は3つの新しいコマンドを提供します: モードストリーム、チェック、およびTAKETHIS。 この拡大のための能力ラベルはSTREAMINGです。
2.1. Streaming Article Transfer
2.1. ストリーミングの記事転送
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コマンドへの質問と転送の機能性を提供します。 これは、pipelinedされるべきコマンド([NNTP]セクション3.5)をCHECKとTAKETHISに許容して、「ストリーミング」の記事転送に備えます。
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コマンドのpipelined系列によって送られる商品目録を構成するのに応答を使用して、その結果、記事を移しながら費やされた時間の部分を増強するのがそうするでしょう。 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を通して記事を送るかもしれません。 こんなやり方でサイトの管理者でそうバンドの外のベースの情報をするために明らかに構成されない場合、クライアントSHOULD NOTはあらゆる記事を送ります。 しかしながら、クライアントは、すべての記事に、それが初めはコマンドをCHECKに送る適応戦略を使用するかもしれませんが、ほとんどの記事を受け入れているなら(95%以上の承認は妥当なメートル法のコネがいくつかの構成であるならそうするでしょうに)CHECKなしでTAKETHISを使用するのに切り替わります。 クライアントはそのような戦略を使用します、それ。また、SHOULDは輸入手形決済相場が敷居の下にたくさん落下するならすべての記事でCHECKを使用するのに元に戻ります。
Vinocur & Murchison Standards Track [Page 3] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[3ページ]RFC4644NNTP拡張子
2.2. Advertising the STREAMING Extension
2.2. ストリーミングの拡大の広告を出します。
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.
本書では説明されたストリーミングのコマンドをサポートするサーバは能力コマンド([NNTP]セクション5.2)に対応して「ストリーミング」の能力ラベルの広告を出すでしょう。 サーバは、クライアントがMODE STREAMコマンドを発行した後にこの能力の広告を出し続けなければなりません。 ともにMODE READERコマンド([NNTP]セクション5.3)のどんな使用の前後にもこの能力の広告を出すかもしれません、同じ意味論で。
Example of a client using CAPABILITIES and MODE STREAM on a mode- switching server:
モード切り換えサーバでCAPABILITIESと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]101Capabilityは記載します: [S]バージョン2[S]MODE-読者[S]IHAVE[S]LIST ACTIVE[S]STREAMING[S] [C] MODE STREAM[S]203Streamingは[C]CAPABILITIES[S]101Capabilityリストを可能にしました: [S]バージョン2[S]MODE-読者[S]IHAVE[S]LIST ACTIVE[S]STREAMING[S] [C] MODE READER[S]200Postingは[C]CAPABILITIES[S]101Capabilityリストを許容しました: [S]バージョン2 [S] 読者[S]ポスト[S]のリストのアクティブなニュースグループヘッダー[S]HDR[S]。
Vinocur & Murchison Standards Track [Page 4] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[4ページ]RFC4644NNTP拡張子
2.3. MODE STREAM Command
2.3. モードストリームコマンド
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がコマンドであるとサポートしたかどうか発見するのにクライアントによって使用されました。 このコマンドをCAPABILITIES発見命令を支持して推奨しなく、これらの輸送命令のレガシー実装[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.
MODE STREAMを使用するかもしれないのを除いて、CAPABILITIESがSTREAMING拡張子のサポートがないかどうかサーバをチェックすると命令する新しいクライアントSHOULD使用は後方にようにCAPABILITIES発見がコマンドであるとサポートしないレガシーサーバとの互換性を命令します。 サーバはCAPABILITIES発見命令を使用しないレガシークライアントとの遅れている互換性のための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.
以下に注意してください。 このコマンドはこの仕様の将来のバージョンから移されるかもしれません、したがって、クライアントがどこでも、可能であるところでCAPABILITIESコマンドへの変遷に促されます。
2.3.1. Usage
2.3.1. 用法
Syntax
MODE STREAM
構文モードストリーム
Responses
203 Streaming permitted
応答203Streamingは可能にしました。
2.3.2. Description
2.3.2. 記述
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.
サーバがこの拡大をサポートするなら、それはMODE STREAMコマンドへの203応答を返さなければなりません(議論であるなら501を与えます)。 MODE STREAMコマンドは何らかの方法でサーバ状態に影響してはいけません(名前にもかかわらず、すなわち、それはモード変更ではありません)、したがって、このコマンドはpipelinedされるかもしれません。 サーバは、CHECKかTAKETHISコマンドを受け入れる前にMODE STREAMコマンドがクライアントによって発行されるのを必要としてはいけません。
2.3.3. Examples
2.3.3. 例
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]MODE STREAM[S]501Unknown MODE異形
Example of a client checking the ability to stream articles on a server which supports this extension:
この拡大をサポートするサーバに関する記事を流す能力をチェックするクライアントの例:
Vinocur & Murchison Standards Track [Page 5] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[5ページ]RFC4644NNTP拡張子
[C] MODE STREAM
[S] 203 Streaming permitted
[C] MODE STREAM[S]203Streamingは可能にしました。
2.4. CHECK Command
2.4. チェックコマンド
2.4.1. Usage
2.4.1. 用法
Syntax
CHECK message-id
構文CHECKメッセージイド
Responses
238 message-id Send article to be transferred
431 message-id Transfer not possible; try again later
438 message-id Article not wanted
可能でないわたっている431メッセージイドTransferである応答238メッセージイドSend記事。 もう一度Articleが欲しくなかった後の438メッセージイドを試みてください。
Parameters
message-id = Article message-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の応答の最初のパラメタはパラメタとしてクライアントによってCHECKに提供されたメッセージイドであるに違いありません。
2.4.2. Description
2.4.2. 記述
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コマンドは、クライアントには指定されたメッセージイドがある記事があることをサーバに知らせます。 サーバがその記事のコピーを望んでいるなら、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.
以下に注意してください。 CHECKへの応答は顧問です。 サーバは、要求された通りこれらの応答で振る舞うためにクライアントに頼ってはいけません。
2.4.3. Examples
2.4.3. 例
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] 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>
Vinocur & Murchison Standards Track [Page 6] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[6ページ]RFC4644NNTP拡張子
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] 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>
2.5. TAKETHIS Command
2.5. TAKETHISコマンド
2.5.1. Usage
2.5.1. 用法
A client MUST NOT use this command unless the server advertises the STREAMING capability or returns a 203 response to the MODE STREAM command.
サーバがSTREAMING能力の広告を出すか、またはMODE STREAMコマンドへの203応答を返さない場合、クライアントはこのコマンドを使用してはいけません。
Syntax
TAKETHIS message-id
構文TAKETHISメッセージイド
Responses
239 message-id Article transferred OK
439 message-id Transfer rejected; do not retry
Transferが拒絶した応答239のメッセージイドのArticleのわたっているOK439メッセージイド。 再試行しないでください。
Parameters
message-id = Article message-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に提供されたメッセージイドであるに違いありません。
2.5.2. Description
2.5.2. 記述
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コマンドを使用します。記事をすぐに、TAKETHISコマンドラインの端でCRLFに続かせます。 クライアントは全体の記事を送らなければなりません、ヘッダーとボディーを含んでいて、マルチ系列データ・ブロック([NNTP]セクション3.1.1)としてのサーバに。 その結果、ただ一つのドット、(「」、)、aでは、系列はテキストの端を示して、原本のドットから始まる系列はトランスミッションの間、そのドットを倍にします。 サーバは239応答、記事が首尾よく移されたのを示すか、または439応答を返さなければなりません、記事が拒絶されたのを示して。 サーバがそれが記事を処理するのを防ぎますが、記事を拒絶したがっていない一時的な誤りに遭遇するなら、それは、クライアントへの400応答で返答して、接続を終えなければなりません。
This function differs from the POST command in that it is intended for use in transferring already-posted articles between hosts. It
この機能は既に掲示された記事をホストの間に移すことにおける使用のために意図するという点においてポストコマンドと異なっています。 それ
Vinocur & Murchison Standards Track [Page 7] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[7ページ]RFC4644NNTP拡張子
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.
SHOULD NOTをクライアントが個人的なニュースを閲読するプログラムであるときに、このコマンドの使用が、記事が別のサイトに既に掲示されたのを示すので、使用して、別のホストから単に進めています。 しかしながら、これにもかかわらず、サーバは、記事のさらなる調査の後にそうするのが不適当であると考えるなら、記事を掲示もしませんし、転送もしないのを選ぶかもしれません。 記事のそのようなその後の拒絶の理由が不適当なニュースグループなどの問題を含むかもしれませんか、または配(椎間腔制限、記事の長さ)はヘッダー、および同様のものを誤り伝えました。 通常、これらは必ず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.
クライアントSHOULD NOTは、サーバから肯定的な応答を受けない場合記事が首尾よく移されたと仮定します。できれば、無反応(下げられたネットワーク接続かネットワークタイムアウトなどの)か400応答SHOULDが後で一時障害として扱われて、再び転送を試みさせます。
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応答がある)のうまくいっている転送を承諾しますが、後で静かにそれを捨てるかもしれません。
2.5.3. Examples
2.5.3. 例
Example of streaming two articles to another site (the first article is accepted and the second is rejected):
別のサイト(最初の記事を受け入れます、そして、2番目を拒絶する)へのストリーミングの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 、gt;、[C]経路: pathost!デモ!、どこか、メールでない[C]From: 「デモユーザ、「 <nobody@example.com 、gt;、[C]ニュースグループ:、」 ミスクテスト[C]Subject: 私はただテスト記事[C]日付:です。 1998年10月6日の04:38:40 -0500[C]組織: Com、Exampleサンノゼ、カリフォルニア[C]Message ID: <i.am.an.article.you.will.want@example.com>[C][C]、これはテスト記事です。 [C] [C] TAKETHIS <i.am.an.article.you.have@example.com 、gt;、[C]経路: pathost!デモ!、どこか、メールでない[C]From: 「デモユーザ、「 <nobody@example.com 、gt;、[C]ニュースグループ:、」 ミスクテスト[C]Subject: 私はただテスト記事[C]日付:です。 1998年10月6日の04:38:40 -0500[C]組織: Com、Exampleサンノゼ、カリフォルニア[C]Message ID: <i.am.an.article.you.have@example.com>。[C]
Vinocur & Murchison Standards Track [Page 8] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[8ページ]RFC4644NNTP拡張子
[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 、gt;、[S]439、lt;、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 、gt;、[C]経路: pathost!デモ!、どこか、メールでない[C]From: 「デモユーザ、「 <nobody@example.com 、gt;、[C]ニュースグループ:、」 ミスクテスト[C]Subject: 私はただテスト記事[C]日付:です。 1998年10月6日の04:38:40 -0500[C]組織: Com、Exampleサンノゼ、カリフォルニア[C]Message ID: <i.am.an.article.you.will.want@example.com>[C][C]、これはテスト記事です。 [C] 一時入手できない[S]400サービス[サーバは接続を終えます。]
3. Augmented BNF Syntax for the STREAMING Extension
3. ストリーミングの拡大のための増大しているBNF構文
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]を使用することでSTREAMING拡張子の正式な構文について説明します。 それは[NNTP]のセクション9で構文を広げています、そして、本書では定義されなかった非端末はそこで定義されます。 [NNTP]ABNFはこれらの規則を有効にするのを最初に、試みる前に、インポートされるべきです。
3.1. Commands
3.1. コマンド
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
チェック命令は「チェック」Wメッセージイドモードストリームコマンド=「モード」W「ストリーム」takethis-コマンド=「TAKETHIS」Wとイドを通信させる状態で等しいです。
3.2. Command Datastream
3.2. コマンドDatastream
This syntax extends the non-terminal "command-datastream", which represents the further material sent by the client in the case of streaming commands.
この構文は非端末「コマンド-datastream」を広げています。(それは、ストリーミングのコマンドの場合でクライアントによって送られたさらなる材料を表します)。
Vinocur & Murchison Standards Track [Page 9] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[9ページ]RFC4644NNTP拡張子
command-datastream =/ takethis-datastream
コマンド-datastream=/takethis-datastream
takethis-datastream = encoded-article
takethis-datastreamはコード化された記事と等しいです。
3.3. Responses
3.3. 応答
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
応答439応答438応答431応答239初期の応答内容応答238=/内容/内容/内容/内容/内容
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
「438」SPメッセージイド応答439「431」SPメッセージイド応答438「239」SPメッセージイド応答431「238」SPメッセージイド応答239応答238内容=内容=内容=内容=内容は「439」SPメッセージイドと等しいです。
3.4. Capability Entries
3.4. 能力エントリー
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"
ストリーミングの能力=「ストリーミング」
4. Summary of Response Codes
4. 応答コードの概要
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.
以下による応答コード203Generated モードストリーム意味: ストリーミングは可能にしました。
Response code 238
Generated by: CHECK
1 argument: message-id
Meaning: send article to be transferred.
以下による応答コード238Generated CHECK1議論: メッセージイドMeaning: 記事を送って、移してください。
Vinocur & Murchison Standards Track [Page 10] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[10ページ]RFC4644NNTP拡張子
Response code 239
Generated by: TAKETHIS
1 argument: message-id
Meaning: article transferred OK.
以下による応答コード239Generated TAKETHIS1議論: メッセージイドMeaning: 記事はOKを移しました。
Response code 431
Generated by: CHECK
1 argument: message-id
Meaning: transfer not possible; try again later.
以下による応答コード431Generated CHECK1議論: メッセージイドMeaning: 可能でない転送。 後でもう一度試みてください。
Response code 438
Generated by: CHECK
1 argument: message-id
Meaning: article not wanted.
以下による応答コード438Generated CHECK1議論: メッセージイドMeaning: 欲しくなかった記事。
Response code 439
Generated by: TAKETHIS
1 argument: message-id
Meaning: transfer rejected; do not retry.
以下による応答コード439Generated TAKETHIS1議論: メッセージイドMeaning: 拒絶された転送。 再試行しないでください。
5. Security Considerations
5. セキュリティ問題
No new security considerations are introduced by this extension, beyond those already described in the core specification [NNTP].
どんな新しいセキュリティ問題もこの拡大でコア仕様[NNTP]で既に説明されたものを超えて紹介されません。
6. IANA Considerations
6. IANA問題
This section gives a formal definition of the STREAMING extension as required by Section 3.3.3 of [NNTP] for the IANA registry.
このセクションは必要に応じて.3セクション3.3[NNTP]でSTREAMING拡張子の公式の定義をIANA登録に与えます。
o The STREAMING extension provides for streaming transfer of
articles.
o STREAMING拡張子は記事のストリーミングの転送に備えます。
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つの新しいコマンドを定義して、MODE 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 拡大はサーバか新しいコマンド以外のクライアントの振舞いに影響しません。
Vinocur & Murchison Standards Track [Page 11] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[11ページ]RFC4644NNTP拡張子
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 STREAM、CHECK、およびTAKETHISコマンドはpipelinedされることができます。
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 、gt。
7. Acknowledgements
7. 承認
This document is based heavily on the relevant sections of RFC 2980 [NNTP-COMMON], by Stan Barber.
スタン・バーバーのこのドキュメントはずっしりとRFC2980[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、クライヴFeather、アンドリューGierth、および他のもののものになります、議論における絶え間ない(まだ過疎の)洞察のためのIETF NNTP作業部会のメンバーと同様に。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, October 2006.
[NNTP]はC.、「ネットワークの電子情報を転送するプロトコル(NNTP)」、RFC3977 2006年10月に羽が伸びます。
8.2. Informative References
8.2. 有益な参照
[NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, October
2000.
[NNTP一般的な] バーバー、S.、「一般的なNNTP拡張子」、RFC2980、2000年10月。
Vinocur & Murchison Standards Track [Page 12] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[12ページ]RFC4644NNTP拡張子
Authors' Addresses
作者のアドレス
Jeffrey M. Vinocur Department of Computer Science Upson Hall Cornell University Ithaca, NY 14853
ジェフリー・M.Vinocurコンピュータサイエンス学部Upsonホールコーネル大学イタケー、ニューヨーク 14853
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 Hall285PA15213ピッツバーグ(米国)
EMail: murch@andrew.cmu.edu
メール: murch@andrew.cmu.edu
Vinocur & Murchison Standards Track [Page 13] RFC 4644 NNTP Extension for Streaming Feeds October 2006
2006年10月に給送を流すためのVinocurとマーチソン標準化過程[13ページ]RFC4644NNTP拡張子
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Vinocur & Murchison Standards Track [Page 14]
Vinocurとマーチソン標準化過程[14ページ]
一覧
スポンサーリンク
