Network Working Group C. Feather
Request for Comments: 3977 THUS plc
Obsoletes: 977 October 2006
Updates: 2980
Category: Standards Track
Network News Transfer Protocol (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
抽象
The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP.
ネットワークニュース転送プロトコル（NNTP）は、十年のためにインターネットで使用され、そして使用されている最も一般的なプロトコル（体積比）今日の1残っています。この文書は、RFC 977の代替である、と正式にプロトコル仕様を更新します。これは、RFC 977で、いくつかのあいまいさを明確にいくつかの新しい基本機能を備えており、NNTPに標準化された拡張子を追加するための具体的なメカニズムを提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Author's Note . . . . . . . . . . . . . . . . . . . . . . 4
2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Commands and Responses . . . . . . . . . . . . . . . . . 6
3.1.1. Multi-line Data Blocks . . . . . . . . . . . . . . . . 8
3.2. Response Codes . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Generic Response Codes . . . . . . . . . . . . . . . 10
3.2.1.1. Examples . . . . . . . . . . . . . . . . . . . . 12
3.3. Capabilities and Extensions . . . . . . . . . . . . . . . 14
3.3.1. Capability Descriptions . . . . . . . . . . . . . . . 14
3.3.2. Standard Capabilities . . . . . . . . . . . . . . . . 15
3.3.3. Extensions . . . . . . . . . . . . . . . . . . . . . 16
3.3.4. Initial IANA Register . . . . . . . . . . . . . . . . 18
3.4. Mandatory and Optional Commands . . . . . . . . . . . . . 20
3.4.1. Reading and Transit Servers . . . . . . . . . . . . . 21
3.4.2. Mode Switching . . . . . . . . . . . . . . . . . . . 21
3.5. Pipelining . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . 23
3.6. Articles . . . . . . . . . . . . . . . . . . . . . . . . 24
4. The WILDMAT Format . . . . . . . . . . . . . . . . . . . . . 25
4.1. Wildmat Syntax . . . . . . . . . . . . . . . . . . . . . 26
4.2. Wildmat Semantics . . . . . . . . . . . . . . . . . . . . 26
4.3. Extensions . . . . . . . . . . . . . . . . . . . . . . . 27
4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27
5. Session Administration Commands . . . . . . . . . . . . . . . 28
5.1. Initial Connection . . . . . . . . . . . . . . . . . . . 28
5.2. CAPABILITIES . . . . . . . . . . . . . . . . . . . . . . 29
5.3. MODE READER . . . . . . . . . . . . . . . . . . . . . . . 32
5.4. QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6. Article Posting and Retrieval . . . . . . . . . . . . . . . . 35
6.1. Group and Article Selection . . . . . . . . . . . . . . . 36
6.1.1. GROUP . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1.2. LISTGROUP . . . . . . . . . . . . . . . . . . . . . . 39
6.1.3. LAST . . . . . . . . . . . . . . . . . . . . . . . . 42
6.1.4. NEXT . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2. Retrieval of Articles and Article Sections . . . . . . . 45
6.2.1. ARTICLE . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.3. BODY . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.4. STAT . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3. Article Posting . . . . . . . . . . . . . . . . . . . . . 56
6.3.1. POST . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3.2. IHAVE . . . . . . . . . . . . . . . . . . . . . . . . 58
7. Information Commands . . . . . . . . . . . . . . . . . . . . 61
7.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2. HELP . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3. NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . . 63
7.4. NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.5. Time . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . 66
7.6. The LIST Commands . . . . . . . . . . . . . . . . . . . . 66
7.6.1. LIST . . . . . . . . . . . . . . . . . . . . . . . . 67
7.6.2. Standard LIST Keywords . . . . . . . . . . . . . . . 69
7.6.3. LIST ACTIVE . . . . . . . . . . . . . . . . . . . . . 70
7.6.4. LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . . 71
7.6.5. LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . . 72
7.6.6. LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . . 73
8. Article Field Access Commands . . . . . . . . . . . . . . . . 73
8.1. Article Metadata . . . . . . . . . . . . . . . . . . . . 74
8.1.1. The :bytes Metadata Item . . . . . . . . . . . . . . 74
8.1.2. The :lines Metadata Item . . . . . . . . . . . . . . 75
8.2. Database Consistency . . . . . . . . . . . . . . . . . . 75
8.3. OVER . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.4. LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . . . . 81
8.5. HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.6. LIST HEADERS . . . . . . . . . . . . . . . . . . . . . . 87
9. Augmented BNF Syntax for NNTP . . . . . . . . . . . . . . . . 90
9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 90
9.2. Commands . . . . . . . . . . . . . . . . . . . . . . . . 92
9.3. Command Continuation . . . . . . . . . . . . . . . . . . 93
9.4. Responses . . . . . . . . . . . . . . . . . . . . . . . . 93
9.4.1. Generic Responses . . . . . . . . . . . . . . . . . . 93
9.4.2. Initial Response Line Contents . . . . . . . . . . . 94
9.4.3. Multi-line Response Contents . . . . . . . . . . . . 94
9.5. Capability Lines . . . . . . . . . . . . . . . . . . . . 95
9.6. LIST Variants . . . . . . . . . . . . . . . . . . . . . . 96
9.7. Articles . . . . . . . . . . . . . . . . . . . . . . . . 97
9.8. General Non-terminals . . . . . . . . . . . . . . . . . . 97
9.9. Extensions and Validation . . . . . . . . . . . . . . . . 99
10. Internationalisation Considerations . . . . . . . . . . . . .100
10.1. Introduction and Historical Situation . . . . . . . . . .100
10.2. This Specification . . . . . . . . . . . . . . . . . . .101
10.3. Outstanding Issues . . . . . . . . . . . . . . . . . . .102
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .103
12. Security Considerations . . . . . . . . . . . . . . . . . . .103
12.1. Personal and Proprietary Information . . . . . . . . . .104
12.2. Abuse of Server Log Information . . . . . . . . . . . . .104
12.3. Weak Authentication and Access Control . . . . . . . . .104
12.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . .104
12.5. UTF-8 Issues . . . . . . . . . . . . . . . . . . . . . .105
12.6. Caching of Capability Lists . . . . . . . . . . . . . . .106
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .107
14. References . . . . . . . . . . . . . . . . . . . . . . . . .110
14.1. Normative References . . . . . . . . . . . . . . . . . .110
14.2. Informative References . . . . . . . . . . . . . . . . .110
A. Interaction with Other Specifications . . . . . . . . . . . .112
A.1. Header Folding . . . . . . . . . . . . . . . . . . . . .112
A.2. Message-IDs . . . . . . . . . . . . . . . . . . . . . . .112
A.3. Article Posting . . . . . . . . . . . . . . . . . . . . .114
B. Summary of Commands . . . . . . . . . . . . . . . . . . . . .115
C. Summary of Response Codes . . . . . . . . . . . . . . . . . .117
D. Changes from RFC 977 . . . . . . . . . . . . . . . . . . . .121
This document specifies the Network News Transfer Protocol (NNTP), which is used for the distribution, inquiry, retrieval, and posting of Netnews articles using a reliable stream-based mechanism. For news-reading clients, NNTP enables retrieval of news articles that are stored in a central database, giving subscribers the ability to select only those articles they wish to read.
この文書では、信頼できるストリームベースのメカニズムを使用してネットニュース記事の配信、照会、検索、および投稿のために使用されているネットワークニュース転送プロトコル（NNTP）を指定します。ニュース読み取りクライアントの場合、NNTPは、加入者に、彼らが読みたいものだけ記事を選択する能力を与えて、中央データベースに格納されているニュース記事の検索を可能にします。
The Netnews model provides for indexing, cross-referencing, and expiration of aged messages. NNTP is designed for efficient transmission of Netnews articles over a reliable full duplex communication channel.
ネットニュースのモデルでは、索引付け、相互参照、および高齢者のメッセージの有効期限を提供します。 NNTPは、信頼性の高い全二重通信チャネルを介してネットニュース記事の効率的な伝送のために設計されています。
Although the protocol specification in this document is largely compatible with the version specified in RFC 977 [RFC977], a number of changes are summarised in Appendix D. In particular:
この文書に記載されているプロトコル仕様は、RFC 977 [RFC977]で指定されたバージョンとほぼ互換性があるが、変更の数は、特定の付録Dにまとめます。
o the default character set is changed from US-ASCII [ANSI1986] to UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8);
Oデフォルトの文字セットがUTF-8 [RFC3629]にUS-ASCII [ANSI1986]から変更された（US-ASCIIがUTF-8のサブセットであることに注意してください）。
o a number of commands that were optional in RFC 977 or that have been taken from RFC 2980 [RFC2980] are now mandatory; and
O RFC 977における任意た又はコマンドの数は、[RFC2980]は今や必須であるRFC 2980から取られています。そして
o a CAPABILITIES command has been added to allow clients to determine what functionality is available from a server.
O capabilitiesコマンドは、クライアントがサーバからどのような機能が利用できるかを決定できるようにするために追加されました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for this protocol. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for NNTP is said to be "conditionally compliant".
それはこのプロトコルのMUST要件の一つ以上を満たすために失敗した場合、実装は準拠していません。すべてのMUSTとそのプロトコルのためのすべてのSHOULD要件を満たす実装は「無条件に準拠した」と言われて。すべてのMUST要件ではなく、NNTPのためのすべてのSHOULD要件を満たすものは、「条件付き準拠した」と言われています。
For the remainder of this document, the terms "client" and "client host" refer to a host making use of the NNTP service, while the terms "server" and "server host" refer to a host that offers the NNTP service.
このドキュメントの残りの部分については、用語は、「クライアント」と「クライアントホスト」用語「サーバ」と「サーバ・ホスト」NNTPサービスを提供していますホストを参照しながら、NNTPサービスを利用してホストを参照してください。
This document is written in XML using an NNTP-specific DTD. Custom software is used to convert this to RFC 2629 [RFC2629] format, and then the public "xml2rfc" package to further reduce this to text, nroff source, and HTML.
この文書は、NNTP固有のDTDを使ってXMLで記述されています。カスタムソフトウェアは、RFCに2629 [RFC2629]形式を、これを変換するために使用され、その後、パブリック「xml2rfc」パッケージは、テキスト、nroffのソース、およびHTMLにこれを削減します。
No perl was used in producing this document.
いいえperlはこの文書を製造するのに使用されませんでした。
The following notational conventions are used in this document.
以下の表記規則が本文書で使用されています。
UPPERCASE indicates literal text to be included in the command.
大文字は、コマンドに含まれるリテラルテキストを示します。
lowercase indicates a token described elsewhere.
小文字は別の場所で説明したトークンを示します。
[brackets] indicate that the enclosed material is optional.
[ブラケット]囲まれた材料がオプションであることを示しています。
elliptical indicates that the argument may be repeated any ... marks number of times (it must occur at least once).
楕円は、引数は（それが少なくとも一度出現しなければならない）任意...マークを数回繰り返すことができることを示しています。
vertical|bar indicates a choice of two mutually exclusive arguments (exactly one must be provided).
縦|バーには、二つの相互に排他的な引数（正確に一つが提供されなければならない）の選択を示します。
The name "message-id" for a command or response argument indicates that it is the message-id of an article as described in Section 3.6, including the angle brackets.
コマンドまたは応答引数の名前「メッセージID」は角括弧を含む、セクション3.6で説明したように、物品のメッセージIDであることを示しています。
The name "wildmat" for an argument indicates that it is a wildmat as defined in Section 4. If the argument does not meet the requirements of that section (for example, if it does not fit the grammar of Section 4.1), the NNTP server MAY place some interpretation on it (not specified by this document) or otherwise MUST treat it as a syntax error.
引数の名前「WILDMATは、」第4節で定義されている（それは、セクション4.1の文法に適合しない場合、たとえば）の引数は、そのセクションの要件を満たしていない場合、それはWILDMATであることを示し、NNTPサーバその上で、いくつかの解釈を置くこと（この文書で指定されていない）か、そうでない場合は、構文エラーとして扱わなければなりません。
Responses for each command will be described in tables listing the required format of a response followed by the meaning that should be ascribed to that response.
各コマンドの応答はその応答に起因する必要があります意味が続く応答の必須フォーマットを一覧表に説明します。
The terms "NUL", "TAB", "LF", "CR, and "space" refer to the octets %x00, %x09, %x0A, %x0D, and %x20, respectively (that is, the octets with those codes in US-ASCII [ANSI1986] and thus in UTF-8 [RFC3629]). The term "CRLF" or "CRLF pair" means the sequence CR immediately followed by LF (that is, %x0D.0A). A "printable US-ASCII character" is an octet in the range %x21-7E. Quoted characters refer to the octets with those codes in US-ASCII (so "." and "<" refer to %x2E and %x3C) and will always be printable US-ASCII characters; similarly, "digit" refers to the octets %x30-39.
用語 "NUL"、 "タブ"、 "LF"、「CR、及び "空間" のものと、それぞれオクテット％のX00、％のX09、％のX0A、％x0D、及び％のX20（すなわち、オクテットを指しUS-ASCIIで符号[ANSI1986]したがって、UTF-8 [RFC3629]）である。用語 "CRLF" または "CRLFペアが" シーケンスCRは直ちに（すなわち、％x0D.0Aある）LFが続くことを意味する。A「印刷可能US-ASCII文字は、「レンジ％のx21-7Eでオクテットである。引用符で囲まれた文字は、（そうUS-ASCIIでこれらのコードでオクテットを参照してください」。」と 『<』％のx2Eと％X3Cを参照）、常になります印刷可能なUS-ASCII文字は、同様に、「桁が」オクテット％のx30-39を指します。
A "keyword" MUST consist only of US-ASCII letters, digits, and the characters dot (".") and dash ("-") and MUST begin with a letter. Keywords MUST be at least three characters in length.
「キーワードは」US-ASCII文字だけ、数字で構成しなければならない、との文字がドット（「 『）とダッシュ（』 - 」）と文字で始まる必要があります。キーワードは、長さが少なくとも3つの文字でなければなりません。
Examples in this document are not normative but serve to illustrate usages, arguments, and responses. In the examples, a "[C]" will be used to represent the client host and an "[S]" will be used to represent the server host. Most of the examples do not rely on a particular server state. In some cases, however, they do assume that the currently selected newsgroup (see the GROUP command, Section 6.1.1) is invalid; when so, this is indicated at the start of the example. Examples may use commands or other keywords not defined in this specification (such as an XENCRYPT command). These will be used to illustrate some point and do not imply that any such command is defined elsewhere or needs to exist in any particular implementation.
この文書の例は、規範的ではないが、用法、引数、および応答を説明するのに役立ちます。実施例では、「[C]は、」クライアントホストを表すために使用され、「[S]」サーバホストを表すために使用されるであろう。例のほとんどは、特定のサーバの状態に依存しないでください。いくつかのケースでは、しかし、彼らは、現在選択されているニュースグループは、（GROUPコマンドは、セクション6.1.1を参照）無効であることを前提としています。ときに、これは、例えば開始時に示されています。例としては、（例えばXENCRYPTコマンドとして）本明細書で定義されていないコマンドまたは他のキーワードを使用してもよいです。これらは、いくつかの点を説明するために使用され、そのようなコマンドは、他の場所で定義された、または任意の特定の実装に存在する必要があることを意味するものではありません。
Terms that might be read as specifying details of a client or server implementation, such as "database", are used simply to ease description. Provided that implementations conform to the protocol and format specifications in this document, no specific technique is mandated.
例えば、「データベース」として、クライアントまたはサーバの実装の詳細を、指定として読まれるかもしれない用語は、説明を容易にするために単に使用されています。実装は、この文書に記載されているプロトコルおよびフォーマットの仕様に準拠することを提供、特別な技術が義務付けられていません。
NNTP operates over any reliable bi-directional 8-bit-wide data stream channel. When the connection is established, the NNTP server host MUST send a greeting. The client host and server host then exchange commands and responses (respectively) until the connection is closed or aborted. If the connection used is TCP, then the server host starts the NNTP service by listening on a TCP port. When a client host wishes to make use of the service, it MUST establish a TCP connection with the server host by connecting to that host on the same port on which the server is listening.
NNTPは、任意の信頼できる双方向8ビット幅のデータ・ストリーム・チャネル上で動作します。接続が確立されると、NNTPサーバのホストがあいさつを送らなければなりません。接続がクローズまたは中止されるまで、クライアントホストとサーバーのホストは、（それぞれ）コマンドとレスポンスを交換します。使用されている接続がTCPである場合、サーバホストはTCPポートでリッスンでNNTPサービスを開始します。クライアントホストがサービスを利用したい場合は、サーバーがリッスンしているポートと同じポート上でそのホストに接続することで、サーバのホストとのTCP接続を確立する必要があります。
The character set for all NNTP commands is UTF-8 [RFC3629]. Commands in NNTP MUST consist of a keyword, which MAY be followed by one or more arguments. A CRLF pair MUST terminate all commands. Multiple commands MUST NOT be on the same line. Unless otherwise noted elsewhere in this document, arguments SHOULD consist of printable US-ASCII characters. Keywords and arguments MUST each be separated by one or more space or TAB characters. Command lines MUST NOT exceed 512 octets, which includes the terminating CRLF pair. The arguments MUST NOT exceed 497 octets. A server MAY relax these limits for commands defined in an extension.
すべてのNNTPコマンドの文字セットがUTF-8 [RFC3629]です。 NNTPのコマンドは、1つ以上の引数を続けることができ、キーワード、から構成されなければなりません。 CRLFのペアは、すべてのコマンドを終えなければなりません。複数のコマンドは、同じ行にあってはいけません。そうでない場合は別の場所でこの文書の記載がない限り、引数は印刷可能なUS-ASCII文字で構成する必要があります。キーワードと引数は、それぞれ、1つ以上のスペースまたはタブ文字で区切らなければなりません。コマンドラインは、終端CRLFペアを含む、512個のオクテットを超えてはなりません。引数は497個のオクテットを超えてはなりません。サーバは、拡張子で定義されたコマンドのこれらの制限を緩和するかもしれません。
Where this specification permits UTF-8 characters outside the range of U+0000 to U+007F, implementations MUST NOT use the Byte Order Mark (U+FEFF, encoding %xEF.BB.BF) and MUST use the Word Joiner (U+2060, encoding %xE2.91.A0) for the meaning Zero Width No-Break Space in command lines and the initial lines of responses. Implementations SHOULD apply these same principles throughout.
この仕様は、U + 007FにU + 0000の範囲外のUTF-8文字を許可する場合、実装は、バイトオーダーマーク（U + FEFF、エンコード％のxEF.BB.BF）を使用してはいけませんとWordジョイナー（U +を使用しなければなりません2060年、コマンドラインと応答の最初の行にある意味ゼロ幅ノーブレークスペースのため％xE2.91.A0）をコードします。実装は全体でこれらの同じ原則を適用すべきです。
The term "character" means a single Unicode code point. Implementations are not required to carry out Unicode normalisation. Thus, U+0084 (A-dieresis) is one character, while U+0041 U+0308 (A composed with dieresis) is two; the two need not be treated as equivalent.
用語「文字」は、単一のUnicodeコードポイントを意味しています。実装は、Unicode正規化を実行するために必要とされていません。したがって、U + 0084（A-dieresis）は1つの文字であり、一方、U + 0041 U + 0308（dieresisで構成される）2です。 2は同等に扱われる必要はありません。
Commands may have variants; if so, they use a second keyword immediately after the first to indicate which variant is required. The only such commands in this specification are LIST and MODE. Note that such variants are sometimes referred to as if they were commands in their own right: "the LIST ACTIVE" command should be read as shorthand for "the ACTIVE variant of the LIST command".
コマンドは、バリアントを有していてもよいです。もしそうなら、彼らが必要とされる変異型を示すために、最初の直後に2番目のキーワードを使用します。この仕様では唯一のそのようなコマンドは、LISTとMODEです。 「LIST ACTIVE」コマンドは「LISTコマンドのACTIVE変異体」の省略形として読まれるべきである。このような変異体は、時には彼らは、自分の右のコマンドであるかのように呼ばれていることに注意してください。
Keywords are case insensitive; the case of keywords for commands MUST be ignored by the server. Command and response arguments are case or language specific only when stated, either in this document or in other relevant specifications.
キーワードは大文字と小文字を区別しません。コマンドのキーワードの場合は、サーバによって無視されなければなりません。コマンドと応答の引数は、この文書で、または他の関連する仕様のいずれかで、述べられたときのみの場合または言語固有のものです。
In some cases, a command involves more data than just a single line. The further data may be sent either immediately after the command line (there are no instances of this in this specification, but there are in extensions such as [NNTP-STREAM]) or following a request from the server (indicated by a 3xx response).
いくつかのケースでは、コマンドは1行だけよりも多くのデータを必要とします。さらに、データは直ちにコマンドライン後のいずれかに送信することができる（本明細書ではこれのインスタンスが存在しないが、などの拡張である[NNTP-STREAM]）または（3xx応答によって示される）サーバからの要求次。
Each response MUST start with a three-digit response code that is sufficient to distinguish all responses. Certain valid responses are defined to be multi-line; for all others, the response is contained in a single line. The initial line of the response MUST NOT exceed 512 octets, which includes the response code and the terminating CRLF pair; an extension MAY specify a greater maximum for commands that it defines, but not for any other command. Single-line responses consist of an initial line only. Multi-line responses consist of an initial line followed by a multi-line data block.
各応答は、すべての応答を区別するのに十分である3桁の応答コードで始まらなければなりません。特定の有効回答が複数行になるように定義されています。すべての他人のために、応答は1行に含まれています。応答の最初の行は、応答コードと終端CRLFペアを含む512個のオクテットを超えてはなりません。拡張子はなく、他のコマンドのために、それは定義されたコマンドのためのより大きな最大値を指定するかもしれません。単一行の応答は、初回のみのラインで構成されています。マルチライン応答は、複数行のデータブロックに続く最初の行から成ります。
An NNTP server MAY have an inactivity autologout timer. Such a timer SHOULD be of at least three minutes' duration, with the exception that there MAY be a shorter limit on how long the server is willing to wait for the first command from the client. The receipt of any command from the client during the timer interval SHOULD suffice to reset the autologout timer. Similarly, the receipt of any significant amount of data from a client that is sending a multi-line data block (such as during a POST or IHAVE command) SHOULD suffice to reset the autologout timer. When the timer expires, the server SHOULD close the connection without sending any response to the client.
NNTPサーバはタイマー自動ログアウト無活動を持っているかもしれません。このようなタイマーは、サーバーがクライアントからの最初のコマンドを待つために喜んでどのくらいの短い制限があるかもしれないことを除いて、少なくとも3分の所要時間でなければなりません。タイマー間隔中にクライアントからの任意のコマンドの受信には、自動ログアウトタイマーをリセットするために十分です。同様に、（例えばPOST又はIHAVEコマンド中など）、マルチラインのデータブロックを送信し、クライアントからのデータの任意の有意な量の受信は自動ログアウトタイマをリセットするために十分です。タイマーが満了すると、サーバーはクライアントへの応答を送信せずに接続を閉じる必要があります。
A multi-line data block is used in certain commands and responses. It MUST adhere to the following rules:
複数行のデータブロックは、特定のコマンドおよび応答に使用されます。これは、次の規則に従う必要があります。
1. The block consists of a sequence of zero or more "lines", each being a stream of octets ending with a CRLF pair. Apart from those line endings, the stream MUST NOT include the octets NUL, LF, or CR.
1ブロックは、ゼロ以上の「行」のシーケンスからなるそれぞれはCRLFペアで終了オクテットのストリームです。別にこれらの行末から、ストリームはオクテットNUL、LF、またはCRを含んではいけません。
2. In a multi-line response, the block immediately follows the CRLF at the end of the initial line of the response. When used in any other context, the specific command will define when the block is sent.
マルチライン応答2.、ブロックは直ちに応答の最初の行の末尾にCRLFに続きます。他の文脈で使用される場合、ブロックが送信されると、特定のコマンドを定義します。
3. If any line of the data block begins with the "termination octet" ("." or %x2E), that line MUST be "dot-stuffed" by prepending an additional termination octet to that line of the block.
前記データブロックのいずれかの行が「終端オクテット」（「」または％x2E）で始まる場合、その行は、 『ドット詰め』ブロックの行に追加終端オクテットを付加することでなければなりません。
4. The lines of the block MUST be followed by a terminating line consisting of a single termination octet followed by a CRLF pair in the normal way. Thus, unless it is empty, a multi-line block is always terminated with the five octets CRLF "." CRLF (%x0D.0A.2E.0D.0A).
4.ブロックの行は、通常の方法でCRLFペア続く単一終端オクテットからなる終端ラインが続かなければなりません。それが空でない限り、このように、複数行のブロックは常に5つのオクテットCRLFで終了します「」 CRLF（％のx0D.0A.2E.0D.0A）。
5. When a multi-line block is interpreted, the "dot-stuffing" MUST be undone; i.e., the recipient MUST ensure that, in any line beginning with the termination octet followed by octets other than a CRLF pair, that initial termination octet is disregarded.
前記複数行のブロックが解釈される場合、「ドットスタッフィング」が取り消されなければなりません。すなわち、受信者は最初の終端オクテットが無視され、任意のラインにCRLF対以外のオクテットが続く終端オクテットで始まることを確認しなければなりません。
6. Likewise, the terminating line ("." CRLF or %x2E.0D.0A) MUST NOT be considered part of the multi-line block; i.e., the recipient MUST ensure that any line beginning with the termination octet followed immediately by a CRLF pair is disregarded. (The first CRLF pair of the terminating CRLF "." CRLF of a non-empty block is, of course, part of the last line of the block.)
6.同様に、終端ライン（CRLFまたは％x2E.0D.0A「」）マルチラインブロックの一部と考えてはいけません。すなわち、受信者は、終端オクテットで始まる行は対が無視されるCRLF直後ことを確認しなければなりません。 （終端CRLFの最初のCRLFペア「」空でないブロックのCRLFは、当然のことながら、ブロックの最後の行の一部です。）
Note that texts using an encoding (such as UTF-16 or UTF-32) that may contain the octets NUL, LF, or CR other than a CRLF pair cannot be reliably conveyed in the above format (that is, they violate the MUST requirement above). However, except when stated otherwise, this specification does not require the content to be UTF-8, and therefore (subject to that same requirement) it MAY include octets above and below 128 mixed arbitrarily.
それらはMUST要件に違反、即ち（CRLFペアよりNUL、LF、またはCRが他のオクテットを含んでいてもよい（例えば、UTF-16またはUTF-32など）エンコーディングを使用してテキストを確実上記形式で伝達することができないことに注意してください上記）。ただし、特に明記しない場合を除き、本明細書は、UTF-8であることがコンテンツを必要とせず、したがって、（同じ要件の対象）は任意に混合し128の上方および下方のオクテットを含むかもしれません。
This document does not place any limit on the length of a line in a multi-line block. However, the standards that define the format of articles may do so.
この文書では、複数行のブロック内の行の長さにいかなる制限を課しません。しかし、記事のフォーマットを定義する基準は、そうすることがあります。
Each response MUST begin with a three-digit status indicator. These are status reports from the server and indicate the response to the last command received from the client.
各応答は3桁のステータスインジケータで開始する必要があります。これらは、サーバーからのステータスレポートで、クライアントから受信した最後のコマンドへの応答を示しています。
The first digit of the response broadly indicates the success, failure, or progress of the previous command:
応答の最初の数字は広く前のコマンドの成功、失敗、または進行状況を示します。
1xx - Informative message 2xx - Command completed OK 3xx - Command OK so far; send the rest of it 4xx - Command was syntactically correct but failed for some reason 5xx - Command unknown, unsupported, unavailable, or syntax error
1xx - 有益メッセージの2xx - コマンドはOK 3xxのを完了 - コマンドOK今のところ、 4xxのそれの残りの部分を送信する - コマンドの構文が正しくだったが、何らかの理由の5xxのために失敗しました - コマンドは、未知のサポートされていない、利用できない、または構文エラー
The next digit in the code indicates the function response category:
コード内の次の桁は、機能応答のカテゴリを示します。
x0x - Connection, setup, and miscellaneous messages x1x - Newsgroup selection x2x - Article selection x3x - Distribution functions x4x - Posting x8x - Reserved for authentication and privacy extensions x9x - Reserved for private use (non-standard extensions)
x0x - 接続、セットアップ、およびその他のメッセージX1X - ニュースグループの選択X2X - 記事の選択x3x - 分布関数x4x - 投稿x8x - 認証とプライバシーの拡張のために予約x9x - 私的使用のために予約（非標準の拡張機能）
Certain responses contain arguments such as numbers and names in addition to the status indicator. In those cases, to simplify interpretation by the client, the number and type of such arguments is fixed for each response code, as is whether the code is single-line or multi-line. Any extension MUST follow this principle as well. Note that, for historical reasons, the 211 response code is an exception to this in that the response may be single-line or multi-line depending on the command (GROUP or LISTGROUP) that generated it. In all other cases, the client MUST only use the status indicator itself to determine the nature of the response. The exact response codes that can be returned by any given command are detailed in the description of that command.
特定の応答は、このような状態インジケータに加えて、数字や名前などの引数が含まれています。そのような場合、クライアントにより解釈を簡素化するためにコードが単一行または複数行であるかのように、そのような引数の数とタイプは、各応答コードのために固定されています。任意の拡張子は、同様にこの原則に従わなければなりません。歴史的な理由のために、211応答コードがこの例外に応答がそれを生成したコマンド（GROUPまたはLISTGROUP）に応じて単一行または複数行であってもよいということである、ということに注意してください。他のすべての例では、クライアントは応答の性質を決定するために、ステータスインジケータ自体を使用しなければなりません。任意のコマンドで返される正確な応答コードは、そのコマンドの説明に詳述されています。
Arguments MUST be separated from the numeric status indicator and from each other by a single space. All numeric arguments MUST be in base 10 (decimal) format and MAY have leading zeros. String arguments MUST contain at least one character and MUST NOT contain TAB, LF, CR, or space. The server MAY add any text after the response code or last argument, as appropriate, and the client MUST NOT make decisions based on this text. Such text MUST be separated from the numeric status indicator or the last argument by at least one space.
引数は、単一のスペースで数値ステータスインジケータからおよび互いから分離されなければなりません。すべての数値引数は、ベース10（10進数）形式でなければなりませんし、先行ゼロを持っているかもしれません。文字列引数は、少なくとも一つの文字を含まなければならないし、TAB、LF、CR、またはスペースを含めることはできません。サーバーは、必要に応じて、応答コードまたは最後の引数の後に任意のテキストを追加することができ、クライアントは、このテキストに基づいて判断してはなりません。このようなテキストは、少なくとも1つのスペースで数値ステータスインジケータまたは最後の引数から分離しなければなりません。
The server MUST respond to any command with the appropriate generic response (given in Section 3.2.1) if it represents the situation. Otherwise, each recognized command MUST return one of the response codes specifically listed in its description or in an extension. A server MAY provide extensions to this specification, including new commands, new variants or features of existing commands, and other ways of changing the internal state of the server. However, the server MUST NOT produce any other responses to a client that does not invoke any of the additional features. (Therefore, a client that restricts itself to this specification will only receive the responses that are listed.)
サーバは、それが状況を表す場合（3.2.1節で与えられた）適切な一般的な応答で任意のコマンドに応答しなければなりません。そうでない場合は、各認識されたコマンドは、具体的にはその記述または拡張にリストされた応答コードのいずれかを返さなければなりません。サーバーは、新しいコマンド、新しい変種または既存のコマンドの機能、およびサーバーの内部状態を変更する他の方法を含め、この仕様に拡張を提供することができます。ただし、サーバーは、追加機能のいずれかを起動していないクライアントへの任意の他の応答を生成してはなりません。 （したがって、本明細書に自分自身を制限するクライアントのみ記載されている応答を受信します。）
If a client receives an unexpected response, it SHOULD use the first digit of the response to determine the result. For example, an unexpected 2xx should be taken as success, and an unexpected 4xx or 5xx as failure.
クライアントが予期しない応答を受信した場合、それは結果を決定するために、応答の最初の数字を使用すべきです。例えば、予想外の2xxは成功とみなすべきである、と障害などの予期しないの4xxまたは5xxの。
Response codes not specified in this document MAY be used for any installation-specific additional commands also not specified. These SHOULD be chosen to fit the pattern of x9x specified above.
この文書で指定されていないレスポンスコードも指定されていないインストール固有の追加のコマンドのために使用されるかもしれません。これらは、上記で指定x9xのパターンに合わせて選択する必要があります。
Neither this document nor any registered extension (see Section 3.3.3) will specify any response codes of the x9x pattern. (Implementers of extensions are accordingly cautioned not to use such responses for extensions that may subsequently be submitted for registration.)
この文書にも登録されているすべての拡張子（セクション3.3.3を参照）のいずれもがx9xパターンのいずれかの応答コードを指定します。 （拡張子の実装者は、それに応じて、その後、登録のために提出することができる拡張のためにそのような応答を使用しないように注意してください。）
The server MUST respond to any command with the appropriate one of the following generic responses if it represents the situation.
それは状況を表している場合、サーバーは、次の一般的な応答の適切なもので、任意のコマンドに反応しなければなりません。
If the command is not recognized, or if it is an optional command that is not implemented by the server, the response code 500 MUST be returned.
コマンドが認識されない場合、それはサーバによって実装されていないオプションのコマンドがある場合、または、レスポンスコード500が返されなければなりません。
If there is a syntax error in the arguments of a recognized command, including the case where more arguments are provided than the command specifies or the command line is longer than the server accepts, the response code 501 MUST be returned. The line MUST NOT be truncated or split and then interpreted. Note that where a command has variants depending on a second keyword (e.g., LIST ACTIVE and LIST NEWSGROUPS), 501 MUST be used when the base command is implemented but the requested variant is not, and 500 MUST be used only when the base command itself is not implemented.
以上の引数がコマンドを指定するか、コマンドラインは、サーバが受け入れるより長いより提供されている場合など、認識されたコマンドの引数、中に構文エラーがある場合は、レスポンスコード501が返されなければなりません。行は切り捨てまたは分割して、解釈してはなりません。コマンド（例えば、LIST ACTIVEおよびLIST NEWSGROUPS）は、第2のキーワードに応じた変異体を有する場合、ベースコマンドが実装されているが、要求された変異体ではない場合、501が使用されなければならないことに注意してください、そして500が使用されなければならない場合にのみ、ベースコマンド自体実装されていません。
If an argument is required to be a base64-encoded string [RFC4648] (there are no such arguments in this specification, but there may be in extensions) and is not validly encoded, the response code 504 MUST be returned.
引数は、base64でエンコードされた文字列[RFC4648]であることが要求される場合（本明細書ではそのような引数が存在しないが、拡張であってもよい）と有効に符号化されていない、レスポンスコード504が返されなければなりません。
If the server experiences an internal fault or problem that means it is unable to carry out the command (for example, a necessary file is missing or a necessary service could not be contacted), the response code 403 MUST be returned. If the server recognizes the command but does not provide an optional feature (for example, because it does not store the required information), or if it only handles a subset of legitimate cases (see the HDR command, Section 8.5, for an example), the response code 503 MUST be returned.
サーバがコマンドを実行できません意味内部障害や問題が発生した場合は、レスポンスコード403が返されなければならない（例えば、必要なファイルが見つからないか、必要なサービスに接続できませんでした）。サーバーは、コマンドを認識するが（それは必要な情報が格納されていないので、例えば）オプション機能を提供していない、またはそれが唯一の合法的な例サブセットを処理する場合した場合（例えば、HDRコマンドは、セクション8.5を参照してください） 、応答コード503が返されなければなりません。
If the client is not authorized to use the specified facility when the server is in its current state, then the appropriate one of the following response codes MUST be used.
クライアントは、サーバが現在の状態にあるときに指定された機能の使用を許可されていない場合は、次の応答コードの適切なものを使用しなければなりません。
502: It is necessary to terminate the connection and to start a new one with the appropriate authority before the command can be used. Historically, some mode-switching servers (see Section 3.4.1) used this response to indicate that this command will become available after the MODE READER command (Section 5.3) is used, but this usage does not conform to this specification and MUST NOT be used. Note that the server MUST NOT close the connection immediately after a 502 response except at the initial connection (Section 5.1) and with the MODE READER command.
502：接続を終了すると、コマンドを使用する前に適切な権限を持つ新しいものを開始する必要があります。歴史的に、この応答を使用（3.4.1項を参照）、いくつかのモード切替のサーバーは、このコマンドが使用されているモードREADERコマンド（5.3節）の後に利用可能になることを示すために、しかし、この使用は、この仕様に準拠していないとしているはずがありません中古。サーバが初期接続（5.1節）とMODEのREADERコマンドを使用して、時を除いて502応答の直後に接続を閉じてはならないことに注意してください。
480: The client must authenticate itself to the server (that is, it must provide information as to the identity of the client) before the facility can be used on this connection. This will involve the use of an authentication extension such as [NNTP-AUTH].
480：ファシリティは、この接続で使用することができます前に、クライアント（つまり、それはクライアントの身元に関する情報を提供しなければならない）サーバーに自身を認証する必要があります。これは、[NNTP-AUTH]として認証拡張の使用を含むであろう。
483: The client must negotiate appropriate privacy protection on the connection. This will involve the use of a privacy extension such as [NNTP-TLS].
483：クライアントが接続上で、適切なプライバシー保護を交渉しなければなりません。これは、[NNTP-TLS]などのプライバシー拡張の使用を伴うだろう。
401: The client must change the state of the connection in some other manner. The first argument of the response MUST be the capability label (see Section 5.2) of the facility that provides the necessary mechanism (usually an extension, which may be a private extension). The server MUST NOT use this response code except as specified by the definition of the capability in question.
401：クライアントは、他の方法で接続の状態を変更する必要があります。応答の最初の引数は（プライベート拡張することができる通常拡張、）必要なメカニズムを提供する施設の能力ラベル（セクション5.2を参照）でなければなりません。サーバーは、問合せの機能の定義によって指定される場合を除き、この応答コードを使用してはなりません。
If the server has to terminate the connection for some reason, it MUST give a 400 response code to the next command and then immediately close the connection. Following a 400 response, clients SHOULD NOT simply reconnect immediately and retry the same actions. Rather, a client SHOULD either use an exponentially increasing delay between retries (e.g., double the waiting time after each 400 response) or present any associated text to the user for them to decide whether and when to retry.
サーバが何らかの理由で接続を終了している場合、それは次のコマンドに400応答コードを与え、その後、すぐに接続を閉じる必要があります。 400応答の後、クライアントは単に、すぐに再接続し、同じアクションを再試行すべきではありません。むしろ、クライアントは再試行間の指数関数的に増加する遅延を使用して（例えば、それぞれ400応答後の待機時間を倍）、またはそれらのかどうか、いつ再試行するかを決定するためにユーザに関連するテキストを提示しなければならないのいずれか。
The client MUST be prepared to receive any of these responses for any command (except, of course, that the server MUST NOT generate a 500 response code for mandatory commands).
クライアントは、（サーバーが必須のコマンドに対する500応答コードを生成してはならないことを、もちろん、を除く）任意のコマンドのためにこれらの応答のいずれかを受け取るために準備しなければなりません。
Example of an unknown command:
未知のコマンドの例：
[C] MAIL [S] 500 Unknown command
[C] MAIL [S] 500不明なコマンド
Example of an unsupported command:
サポートされていないコマンドの例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] NEWNEWS [S] LIST ACTIVE NEWSGROUPS [S] . [C] OVER [S] 500 Unknown command
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] NEWNEWS [S] LIST ACTIVE NEWSGROUPS [S]。 [C] OVER [S] 500不明なコマンド
Example of an unsupported variant:
サポートされていないバリアントの例：
[C] MODE POSTER [S] 501 Unknown MODE option
[C] MODEポスター[S] 501不明MODEオプション
Example of a syntax error:
構文エラーの例：
[C] ARTICLE a.message.id@no.angle.brackets [S] 501 Syntax error
[C]記事のa.message.id@no.angle.brackets [S] 501構文エラー
Example of an overlong command line:
すぎるコマンドラインの例：
[C] HEAD 53 54 55 [S] 501 Too many arguments
[C]ヘッド53 54 55 [S] 501個のが多すぎる引数
Example of a bad wildmat:
悪いWILDMATの例：
[C] LIST ACTIVE u[ks].* [S] 501 Syntax error
[C] LIST ACTIVE U [KS]。* [S] 501構文エラー
Example of a base64-encoding error (the second argument is meant to be base64 encoded):
base64で符号化誤差の一例（第2の引数はbase64エンコードであることを意味します）。
[C] XENCRYPT RSA abcd=efg [S] 504 Base64 encoding error
[C] XENCRYPT RSA ABCD = EFG [S] 504 Base64エンコードエラー
Example of an attempt to access a facility not available to this connection:
この接続に利用できない機能にアクセスしようとする試みの例：
[C] MODE READER [S] 200 Reader mode, posting permitted [C] IHAVE <i.am.an.article.you.will.want@example.com> [S] 500 Permission denied
[C] MODEリーダ[S] 200リーダモード、拒否許可[C] IHAVE <i.am.an.article.you.will.want@example.com> [S] 500許可を転記
Example of an attempt to access a facility requiring authentication:
認証を必要とする施設にアクセスしようとする試みの例：
[C] GROUP secret.group [S] 480 Permission denied
[C]グループsecret.group [S] 480許可拒否
Example of a successful attempt following such authentication:
こうした認証次の成功の試みの例：
[C] XSECRET fred flintstone [S] 290 Password for fred accepted [C] GROUP secret.group [S] 211 5 1 20 secret.group selected
[C] XSECRETフレッドフリントストーンは、[S]フレッド290パスワードが受け入れ[C] GROUP secret.group [S] 211 5 1 20 secret.groupは、選択されました
Example of an attempt to access a facility requiring privacy:
プライバシーを必要とする施設にアクセスしようとする試みの例：
[C] GROUP secret.group [S] 483 Secure connection required [C] XENCRYPT [Client and server negotiate encryption on the link] [S] 283 Encrypted link established [C] GROUP secret.group [S] 211 5 1 20 secret.group selected
[C] GROUP secret.group [S] 483セキュア接続に必要な[C] XENCRYPT [クライアントとサーバがリンク上で暗号化を交渉] [S] 283暗号化されたリンク確立[C] GROUP secret.group [S] 211 5 1 20シークレット.group選択
Example of a need to change mode before a facility is used:
施設が使用される前に、モードを変更する必要性の例：
[C] GROUP binary.group [S] 401 XHOST Not on this virtual host [C] XHOST binary.news.example.org [S] 290 binary.news.example.org virtual host selected [C] GROUP binary.group [S] 211 5 1 77 binary.group selected
[C]グループbinary.group [S] 401でxhostず、この仮想ホストの[C]のxhost binary.news.example.org [S] 290 binary.news.example.org仮想ホスト選択[C]グループbinary.group [ S] 211 5 1 77 binary.groupは、選択されました
Example of a temporary failure:
一時的な障害の例：
[C] GROUP archive.local [S] 403 Archive server temporarily offline
[C] GROUPのarchive.local [S] 403アーカイブサーバーを一時的にオフライン
Example of the server needing to close down immediately:
すぐに閉鎖する必要がサーバーの例：
[C] ARTICLE 123 [S] 400 Power supply failed, running on UPS [Server closes connection.]
[C]第123条[S] 400電源は、UPS上で実行されている、障害が発生した[サーバが接続を閉じます。]
Not all NNTP servers provide exactly the same facilities, both because this specification allows variation and because servers may provide extensions. A set of facilities that are related are called a "capability". This specification provides a way to determine what capabilities are available, includes a list of standard capabilities, and includes a mechanism (the extension mechanism) for defining new capabilities.
すべてではないNNTPサーバは、この仕様が変化を可能にし、サーバーの拡張機能を提供することができるので、両方のため、まったく同じ機能を提供します。関連している施設のセットは、「機能」と呼ばれています。この仕様は、利用可能な機能を決定する方法を提供し、標準機能のリストを含んでおり、新しい機能を定義するための機構（拡張手段）を備えています。
A client can determine the available capabilities of the server by using the CAPABILITIES command (Section 5.2). This returns a capability list, which is a list of capability lines. Each line describes one available capability.
クライアントは、capabilitiesコマンド（5.2節）を使用して、サーバーの利用できる機能を判断することができます。これは、機能行のリストである機能の一覧を返します。各行は、1つの可能な機能を説明します。
Each capability line consists of one or more tokens, which MUST be separated by one or more space or TAB characters. A token is a string of 1 or more printable UTF-8 characters (that is, either printable US-ASCII characters or any UTF-8 sequence outside the US-ASCII range, but not space or TAB). Unless stated otherwise, tokens are case insensitive. Each capability line consists of the following:
各能力ラインは、一つ以上のスペースまたはタブ文字で分離されなければならない一つまたは複数のトークンからなります。トークンは（、印刷可能なUS-ASCII文字またはUS-ASCIIの範囲外の任意のUTF-8シーケンスではなく、スペースまたはTABのいずれかであることが）1以上の印刷可能なUTF-8文字の文字列です。特に明記しない限り、トークンは大文字と小文字を区別しません。各機能ラインの構成は次のとおりです。
o The capability label, which is a keyword indicating the capability. A capability label may be defined by this specification or a successor, or by an extension.
能力を示すキーワードである、能力ラベル、O。能力ラベルは、本明細書または後続によって、または拡張によって定義されてもよいです。
o The label is then followed by zero or more tokens, which are arguments of the capability. The form and meaning of these tokens is specific to each capability.
Oラベルは、その後、機能の引数はゼロ以上のトークンが続きます。これらのトークンの形式と意味は、各機能に固有のものです。
The server MUST ensure that the capability list accurately reflects the capabilities (including extensions) currently available. If a capability is only available with the server in a certain state (for example, only after authentication), the list MUST only include the capability label when the server is in that state. Similarly, if only some of the commands in an extension will be available, or if the behaviour of the extension will change in some other manner, according to the state of the server, this MUST be indicated by different arguments in the capability line.
サーバーは、能力リストは正確に現在利用可能な（拡張子を含む）の能力を反映していることを保証しなければなりません。機能は、（例えば、唯一の認証後）、特定の状態にあるサーバーでのみ使用可能な場合、サーバがその状態である場合、リストには、能力ラベルを含まなければなりません。同様に、唯一のいくつかの拡張のコマンドのは、利用できるようになり、または拡張の動作は、他の方法で変更された場合、サーバの状態に応じて、これは機能ラインの異なる引数によって示さなければなりません。
Note that a capability line can only begin with a letter. Lines beginning with other characters are reserved for future versions of this specification. In order to interoperate with such versions, clients MUST be prepared to receive lines beginning with other characters and MUST ignore any they do not understand.
機能ラインのみが文字で始まることに注意してください。他の文字で始まる行は、この仕様の将来のバージョンのために予約されています。そのようなバージョンと相互運用するためには、クライアントが他の文字で始まる行を受け取るために準備しなければなりませんし、彼らが理解していない任意のを無視しなければなりません。
The following capabilities are defined by this specification.
次の機能は、この仕様で定義されています。
VERSION This capability MUST be advertised by all servers and MUST be the first capability in the capability list; it indicates the version(s) of NNTP that the server supports. There must be at least one argument; each argument is a decimal number and MUST NOT have a leading zero. Version numbers are assigned only in RFCs that update or replace this specification; servers MUST NOT create their own version numbers.
VERSIONこの機能は、すべてのサーバによってアドバタイズされなければならないと能力リストの最初の能力でなければなりません。それは、サーバがサポートしているNNTPのバージョン（複数可）を示しています。少なくとも一つの引数がなければなりません。各引数は10進数です、先頭にゼロを持ってはいけません。バージョン番号は、唯一、この仕様を置き換える更新またはRFCで割り当てられます。サーバーは、独自のバージョン番号を作成してはいけません。
The version number of this specification is 2.
この仕様のバージョン番号は2です。
READER This capability indicates that the server implements the various commands useful for reading clients.
READERこの機能は、サーバーがクライアントを読み取るための有用な様々なコマンドを実装していることを示しています。
IHAVE This capability indicates that the server implements the IHAVE command.
私は、この機能は、サーバーがI HAVEコマンドを実装していることを示しHAVE。
POST This capability indicates that the server implements the POST command.
POSTこの機能は、サーバーがPOSTコマンドを実装していることを示しています。
NEWNEWS This capability indicates that the server implements the NEWNEWS command.
NEWNEWSこの機能は、サーバーがNEWNEWSコマンドを実装していることを示しています。
HDR This capability indicates that the server implements the header access commands (HDR and LIST HEADERS).
HDRは、この機能は、サーバが、ヘッダ・アクセス・コマンド（HDRとLISTヘッダー）を実装することを示しています。
OVER This capability indicates that the server implements the overview access commands (OVER and LIST OVERVIEW.FMT). If and only if the server supports the message-id form of the OVER command, there must be a single argument MSGID.
この機能上のサーバが概要アクセスコマンド（OVERとLIST OVERVIEW.FMT）を実装していることを示しています。そして、サーバがOVERコマンドのメッセージIDの形式をサポートしている場合にのみ場合は、単一の引数MSGIDがなければなりません。
LIST This capability indicates that the server implements at least one variant of the LIST command. There MUST be one argument for each variant of the LIST command supported by the server, giving the keyword for that variant.
LISTは、この機能は、サーバーはLISTコマンドの少なくとも一つの変異体を実装していることを示しています。そのバリエーションのキーワードを与え、サーバーによってサポートさLISTコマンドの各バリアントのための1つの引数があるに違いありません。
IMPLEMENTATION This capability MAY be provided by a server. If so, the arguments SHOULD be used to provide information such as the server software name and version number. The client MUST NOT use this line to determine capabilities of the server. (While servers often provide this information in the initial greeting, clients need to guess whether this is the case; this capability makes it clear what the information is.)
実装は、この機能は、サーバによって提供されてもよいです。もしそうなら、引数は、サーバソフトウェアの名前とバージョン番号などの情報を提供するために使用されるべきです。クライアントは、サーバーの能力を決定するために、このラインを使用してはなりません。 （サーバは、多くの場合、最初の挨拶で、この情報を提供しているが、クライアントがこれに該当するかどうかを推測する必要があります。この機能は、それが明確にどのような情報であることができます。）
MODE-READER This capability indicates that the server is mode-switching (Section 3.4.2) and that the MODE READER command needs to be used to enable the READER capability.
MODE-READERは、この機能は、サーバが、モード切り替え（セクション3.4.2）とMODEリーダコマンドがリーダ機能を有効にするために使用する必要があることであることを示しています。
Although NNTP is widely and robustly deployed, some parts of the Internet community might wish to extend the NNTP service. It must be emphasized that any extension to NNTP should not be considered lightly. NNTP's strength comes primarily from its simplicity. Experience with many protocols has shown that:
NNTPが広くかつ確実に配備されているが、インターネットコミュニティの一部には、NNTPサービスを拡張することを望むかもしれません。 NNTPに任意の拡張子を軽く考えるべきではないことを強調しなければなりません。 NNTPの強みはそのシンプルさから主に来ます。多くのプロトコルでの経験はそれを示しています。
Protocols with few options tend towards ubiquity, whilst protocols with many options tend towards obscurity.
多くのオプションを持つプロトコルが曖昧に向かう傾向がある一方で、いくつかのオプションを持つプロトコルは、ユビキタスに向かう傾向。
This means that each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs. In many cases, the cost of extending the NNTP service will likely outweigh the benefit.
これは、その一人ひとりの拡張を意味し、関係なく、その利点を、慎重にその実装、展開、および相互運用コストに関して精査する必要があります。多くの場合、NNTPサービスを拡張するコストが便益を上回る可能性が高いでしょう。
An extension is a package of associated facilities, often but not always including one or more new commands. Each extension MUST define at least one new capability label (this will often, but need not, be the name of one of these new commands). While any additional capability information can normally be specified using arguments to that label, an extension MAY define more than one capability label. However, this SHOULD be limited to exceptional circumstances.
拡張子は、多くの場合、常にではないが1つまたは複数の新しいコマンドを含む、関連する施設のパッケージです。それぞれの拡張子は（これはしばしば意志、必須ではないが、これらの新しいコマンドのいずれかの名前である）少なくとも1つの新しい機能ラベルを定義しなければなりません。追加の能力情報は、通常、そのラベルに引数を使用して指定することができますが、拡張機能は、複数の機能ラベルを定義することができます。しかし、これは例外的な状況に限定されるべきです。
An extension is either a private extension, or its capabilities are included in the IANA registry of capabilities (see Section 3.3.4) and it is defined in an RFC (in which case it is a "registered extension"). Such RFCs either must be on the standards track or must define an IESG-approved experimental protocol.
拡張子はどちらかのプライベート拡張である、またはその能力は能力（セクション3.3.4を参照）のIANAレジストリに含まれており、それが（その場合、それは、「登録された拡張子」である）RFCで定義されています。このようなRFCは標準化過程の上でなければならないか、IESGが承認した実験プロトコルを定義する必要があります。
The definition of an extension must include the following:
拡張子の定義は、以下を含める必要があります。
o a descriptive name for the extension.
拡張機能の説明的な名前O。
o the capability label or labels defined by the extension (the capability label of a registered extension MUST NOT begin with "X").
O機能ラベルまたは拡張によって定義されたラベル（登録延長の能力ラベルは、「X」で始めてはいけません）。
o The syntax, values, and meanings of any arguments for each capability label defined by the extension.
拡張によって定義された各機能のラベルのための任意の引数の構文、値、および意味は、O。
o Any new NNTP commands associated with the extension (the names of commands associated with registered extensions MUST NOT begin with "X").
拡張子に関連付けられているすべての新しいNNTPコマンドO（登録拡張子に関連付けられたコマンドの名前が「X」で始めることはできません）。
o The syntax and possible values of arguments associated with the new NNTP commands.
新しいNNTPコマンドに関連付けられた引数の構文と可能な値O。
o The response codes and possible values of arguments for the responses of the new NNTP commands.
応答コードと新しいNNTPコマンドのレスポンスの引数の取り得る値O。
o Any new arguments the extension associates with any other pre-existing NNTP commands.
Oすべての新しい引数が他の既存のNNTPコマンドで延長会合します。
o Any increase in the maximum length of commands and initial response lines over the value specified in this document.
この文書で指定された値を超えるコマンドと初期応答行の最大長さの増加、O。
o A specific statement about the effect on pipelining that this extension may have (if any).
この拡張は（もしあれば）を有することができるパイプラインへの影響についての具体的な声明O。
o A specific statement about the circumstances when use of this extension can alter the contents of the capabilities list (other than the new capability labels it defines).
この拡張機能を使用するには（それが定義する新しい機能ラベル以外）の機能リストの内容を変更することができ事情についての具体的な声明O。
o A specific statement about the circumstances under which the extension can cause any pre-existing command to produce a 401, 480, or 483 response.
O拡張は、任意の既存のコマンド401、480、または483応答を生成させることができるれる状況に関する特定のステートメント。
o A description of how the use of MODE READER on a mode-switching server interacts with the extension.
モード切替サーバー上のMODE READERの使用が拡張とどのように相互作用するかの説明O。
o A description of how support for the extension affects the behaviour of a server and NNTP client in any other manner not outlined above.
O拡張のサポートは、上記の概説ではない、他の方法で、サーバーおよびNNTPクライアントの動作にどのように影響するかについての説明。
o Formal syntax as described in Section 9.9.
セクション9.9で説明したように正式な構文O。
A private extension MAY or MAY NOT be included in the capabilities list. If it is, the capability label MUST begin with "X". A server MAY provide additional keywords (for new commands and also for new variants of existing commands) as part of a private extension. To avoid the risk of a clash with a future registered extension, these keywords SHOULD begin with "X".
プライベート拡張子がまたは機能のリストに含まれていてもいなくてもよいです。もしそうであれば、機能ラベルが「X」で始まる必要があります。サーバーは、プライベート拡張の一環として、（既存のコマンドの新しい亜種にも新しいコマンドのためにと）追加のキーワードを提供することができます。将来の登録拡張子との衝突の危険を回避するために、これらのキーワードは、「X」で開始する必要があります。
If the server advertises a capability defined by a registered extension, it MUST implement the extension so as to fully conform with the specification (for example, it MUST implement all the commands that the extension describes as mandatory). If it does not implement the extension as specified, it MUST NOT list the extension in the capabilities list under its registered name. In that case, it MAY, but SHOULD NOT, provide a private extension (not listed, or listed with a different name) that implements part of the extension or implements the commands of the extension with a different meaning.
サーバは、登録拡張によって定義された能力をアドバタイズした場合、完全に（例えば、それは拡張が必須として説明したすべてのコマンドを実装しなければならない）仕様に準拠するように、それは拡張を実装しなければなりません。指定されたとして、それが拡張を実装していない場合は、その登録名の下に機能リストに拡張子をリストしてはなりません。その場合には、それは、しかしべきではありません、拡張の一部を実装して、異なる意味を持つ拡張のコマンドを実装プライベート拡張子（いない記載されている、または別の名前で記載されている）を提供することができます。
A server MUST NOT send different response codes to basic NNTP commands documented here or to commands documented in registered extensions in response to the availability or use of a private extension.
サーバーは、ここに文書化され、基本的なNNTPコマンドにまたは可用性やプライベート拡張の使用に応じて、登録した拡張子に記載のコマンドに異なる応答コードを送ってはいけません。
IANA will maintain a registry of NNTP capability labels. All capability labels in the registry MUST be keywords and MUST NOT begin with X.
IANAは、NNTP機能ラベルのレジストリを維持します。レジストリのすべての機能ラベルは、キーワードでなければならないとX.で始めてはいけません
The initial content of the registry consists of these entries:
レジストリの初期コンテンツは、これらのエントリで構成されています。
+-------------------+--------------------------+--------------------+
| Label | Meaning | Definition |
+-------------------+--------------------------+--------------------+
| AUTHINFO | Authentication | [NNTP-AUTH] |
| | | |
| HDR | Batched header retrieval | Section 3.3.2, |
| | | Section 8.5, and |
| | | Section 8.6 |
| | | |
| IHAVE | IHAVE command available | Section 3.3.2 and |
| | | Section 6.3.2 |
| | | |
| IMPLEMENTATION | Server | Section 3.3.2 |
| | implementation-specific | |
| | information | |
| | | |
| LIST | LIST command variants | Section 3.3.2 and |
| | | Section 7.6.1 |
| | | |
| MODE-READER | Mode-switching server | Section 3.4.2 |
| | and MODE READER command | |
| | available | |
| | | |
| NEWNEWS | NEWNEWS command | Section 3.3.2 and |
| | available | Section 7.4 |
| | | |
| OVER | Overview support | Section 3.3.2, |
| | | Section 8.3, and |
| | | Section 8.4 |
| | | |
| POST | POST command available | Section 3.3.2 and |
| | | Section 6.3.1 |
| | | |
| READER | Reader commands | Section 3.3.2 |
| | available | |
| | | |
| SASL | Supported SASL | [NNTP-AUTH] |
| | mechanisms | |
| | | |
| STARTTLS | Transport layer security | [NNTP-TLS] |
| | | |
| STREAMING | Streaming feeds | [NNTP-STREAM] |
| | | |
| VERSION | Supported NNTP versions | Section 3.3.2 |
+-------------------+--------------------------+--------------------+
For a number of reasons, not all the commands in this specification are mandatory. However, it is equally undesirable for every command to be optional, since this means that a client will have no idea what facilities are available. Therefore, as a compromise, some of the commands in this specification are mandatory (they must be supported by all servers) while the remainder are not. The latter are then subdivided into bundles, each indicated by a single capability label.
多くの理由により、この仕様ではなく、すべてのコマンドが必須です。これは、クライアントが利用可能な施設見当がつかないことを意味しますので、しかし、すべてのコマンドはオプションであるためにも同様に望ましくありません。残りはありませんしつつ、妥協案として、この仕様でコマンドの一部は、（彼らはすべてのサーバによってサポートされなければならない）は必須です。後者は、その後、それぞれが単一の機能ラベルで示され、束に細分されます。
o If the label is included in the capability list returned by the server, the server MUST support all commands in that bundle.
ラベルは、サーバから返された能力のリストに含まれている場合は、O、サーバはそのバンドル内のすべてのコマンドをサポートしなければなりません。
o If the label is not included, the server MAY support none or some of the commands but SHOULD NOT support all of them. In general, there will be no way for a client to determine which commands are supported without trying them.
ラベルが含まれていない場合は、O、サーバーはどれか、いくつかのコマンドをサポートしていないかもしれないが、それらのすべてをサポートすべきではありません。一般的には、それらをしようとせず、サポートされているコマンドを決定するために、クライアントのための方法がないでしょう。
The bundles have been chosen to provide useful functionality, and therefore server authors are discouraged from implementing only part of a bundle.
バンドルは、便利な機能を提供するように選択されているので、サーバーの作者は、バンドルの一部のみを実装するから、落胆しています。
The description of each command will either indicate that it is mandatory, or will give, using the term "indicating capability", the capability label indicating whether the bundle including this command is available.
各コマンドの説明は、このコマンドを含むバンドルが利用可能であるかどうかを示す、「能力を示す」という用語を使用して、機能ラベルのいずれかが必須であることを示すか、または与えます。
Where a server does not implement a command, it MUST always generate a 500 generic response code (or a 501 generic response code in the case of a variant of a command depending on a second keyword where the base command is recognised). Otherwise, the command MUST be fully implemented as specified; a server MUST NOT only partially implement any of the commands in this specification. (Client authors should note that some servers not conforming to this specification will return a 502 generic response code to some commands that are not implemented.)
サーバーがコマンドを実装していない場合、それは常に500汎用の応答コード（またはベースコマンドが認識された第二のキーワードに応じて、コマンドの変異体の場合には501、汎用レスポンスコード）を生成しなければなりません。そうしないと、コマンドは完全に指定されているように実装されなければなりません。サーバーは、部分的にしかこの仕様でコマンドのいずれかを実装してはなりません。 （クライアントの作者はこの仕様に準拠していない一部のサーバーが実装されていないいくつかのコマンドに502一般的な応答コードを返すことに注意してください。）
Note: some commands have cases that require other commands to be used first. If the former command is implemented but the latter is not, the former MUST still generate the relevant specific response code. For example, if ARTICLE (Section 6.2.1) is implemented but GROUP (Section 6.1.1) is not, the correct response to "ARTICLE 1234" remains 412.
注意：いくつかのコマンドが最初に使用される他のコマンドが必要な場合があります。前者のコマンドが実装が、後者ではないれている場合、前者は依然として関連する特定の応答コードを生成しなければなりません。 ARTICLE（セクション6.2.1）が実装が、グループ（セクション6.1.1）がでない場合、例えば、「ARTICLE 1234」への正しい応答は412のままです。
NNTP is traditionally used in two different ways. The first use is "reading", where the client fetches articles from a large store maintained by the server for immediate or later presentation to a user and sends articles created by that user back to the server (an action called "posting") to be stored and distributed to other stores and users. The second use is for the bulk transfer of articles from one store to another. Since the hosts making this transfer tend to be peers in a network that transmit articles among one another, and not end-user systems, this process is called "peering" or "transit". (Even so, one host is still the client and the other is the server).
NNTPは伝統的に2つの異なる方法で使用されています。最初の使用は、クライアントがユーザーへの即時以降のプレゼンテーションのために、サーバによって維持大型店から物品を取り出し、バックサーバになるように（「投稿」と呼ばれるアクション）に、そのユーザーが作成した記事を送り「読書」であり、格納され、他の格納してユーザに配布。二次利用は、別のストアからの記事のバルク転送のためです。この転送を行うホストが互いの間で物品を送信するネットワーク内のピアになる傾向があり、そしてエンドユーザーのないシステムをので、このプロセスは「ピアリング」または「トランジット」と呼ばれます。 （そうであっても、一つのホストは、まだクライアントであり、他方はサーバーです）。
In practice, these two uses are so different that some server implementations are optimised for reading or for transit and, as a result, do not offer the other facility or only offer limited features. Other implementations are more general and offer both. This specification allows for this by bundling the relevant commands accordingly: the IHAVE command is designed for transit, while the commands indicated by the READER capability are designed for reading clients.
実際には、これらの2つの用途には、いくつかのサーバ実装は、読み取り用または輸送用に最適化されており、結果として、他の施設を提供したり、限られた機能を提供しないように異なっています。他の実装は、より一般的であり、両方を提供します。リーダ能力によって示されるコマンドはクライアントを読み取るために設計されている間IHAVEコマンドは、輸送のために設計されている：この仕様は、それに応じて、関連するコマンドをバンドルすることによってこれを可能にします。
Except as an effect of the MODE READER command (Section 5.3) on a mode-switching server, once a server advertises either or both of the IHAVE or READER capabilities, it MUST continue to advertise them for the entire session.
モード切替サーバーのMODE READERコマンド（5.3節）の効果などを除き、サーバはIHAVEまたはReaderの機能のいずれかまたは両方をアドバタイズしたら、それはセッション全体のためにそれらを宣伝し続けなければなりません。
A server MAY provide different modes of behaviour (transit, reader, or a combination) to different client connections and MAY use external information, such as the IP address of the client, to determine which mode to provide to any given connection.
サーバは、任意の所与の接続を提供するためにどのモードを決定するために、そのようなクライアントのIPアドレスとして、異なったクライアント接続に動作の異なるモード（トランジット、リーダ、またはこれらの組み合わせ）を提供することができ、外部の情報を使用することができます。
The official TCP port for the NNTP service is 119. However, if a host wishes to offer separate servers for transit and reading clients, port 433 SHOULD be used for the transit server and 119 for the reading server.
ホストはトランジットとクライアントを読み取るための別々のサーバーを提供することを希望する場合NNTPサービスのための公式のTCPポートが、しかし119で、ポート433は、読み取りサーバーの中継サーバーと119のために使用されるべきです。
An implementation MAY, but SHOULD NOT, provide both transit and reader facilities on the same server but require the client to select which it wishes to use. Such an arrangement is called a "mode-switching" server.
実装は、しかしべきではない、同じサーバー上の両方のトランジットと読者の設備を提供しますが、それが使用したいかを選択するためにクライアントが必要な場合があります。このような構成は、「モード切替」サーバーと呼ばれています。
A mode-switching server has two modes:
モード切替サーバーは、2つのモードがあります。
o Transit mode, which applies after the initial connection.
初期接続後に適用されるOトランジットモード、。
* It MUST advertise the MODE-READER capability.
*これは、MODE-READERの機能をアドバタイズする必要があります。
* It MUST NOT advertise the READER capability.
*これは、READERの機能をアドバタイズしてはなりません。
However, the server MAY cease to advertise the MODE-READER capability after the client uses any command except CAPABILITIES.
ただし、サーバーは、クライアントがケーパビリティを除く任意のコマンドを使用した後、MODE-READERの機能をアドバタイズしなくなる可能性があります。
o Reading mode, after a successful MODE READER command (see Section 5.3).
成功MODEのREADERコマンドの後に、モードを読むO（5.3節を参照してください）。
* It MUST NOT advertise the MODE-READER capability.
*これは、MODE-READERの機能をアドバタイズしてはなりません。
* It MUST advertise the READER capability.
*これは、READERの機能をアドバタイズする必要があります。
* It MAY NOT advertise the IHAVE capability, even if it was advertising it in transit mode.
*それはトランジットモードで宣伝された場合でも、IHAVEの機能をアドバタイズされない場合があります。
A client SHOULD only issue a MODE READER command to a server if it is advertising the MODE-READER capability. If the server does not support CAPABILITIES (and therefore does not conform to this specification), the client MAY use the following heuristic:
それはMODE-READER機能を宣伝している場合、クライアントはサーバーにMODEのREADERコマンドを発行する必要があります。サーバが機能をサポートしていません（そのため、この仕様に準拠していない）場合、クライアントは次のヒューリスティックを使用することもできます。
o If the client wishes to use any "reader" commands, it SHOULD use the MODE READER command immediately after the initial connection.
クライアントが「リーダー」コマンドを使用したい場合は、O、それは最初の接続直後のMODE READERコマンドを使用すべきです。
o Otherwise, it SHOULD NOT use the MODE READER command.
Oそれ以外の場合は、MODEのREADERコマンドを使用しないでください。
In each case, it should be prepared for some commands to be unavailable that would have been available if it had made the other choice.
それぞれのケースで、他の選択をした場合は利用可能であったであろうその利用できなくするためにいくつかのコマンドのために準備する必要があります。
NNTP is designed to operate over a reliable bi-directional connection, such as TCP. Therefore, if a command does not depend on the response to the previous one, it should not matter if it is sent before that response is received. Doing this is called "pipelining". However, certain server implementations throw away all text received from the client following certain commands before sending their response. If this happens, pipelining will be affected because one or more commands will have been ignored or misinterpreted, and the client will be matching the wrong responses to each command. Since there are significant benefits to pipelining, but also circumstances where it is reasonable or common for servers to behave in the above manner, this document puts certain requirements on both clients and servers.
NNTPは、TCPのような信頼性の高い双方向接続を介して動作するように設計されています。コマンドは、前の1への応答に依存していない場合に、応答が受信される前に、それが送られた場合ので、それは問題ではないはずです。これを行うと、「パイプライン」と呼ばれています。ただし、特定のサーバーの実装は、すべてのテキストが彼らの応答を送信する前に特定のコマンドを次のクライアントから受け取っ捨てます。この問題が発生した場合は、1つまたは複数のコマンドが無視されたり誤解されていますので、パイプラインが影響を受けることになりますし、クライアントは、各コマンドに誤った応答をマッチングされます。重要なパイプラインへのメリットだけでなく、サーバは上記のように動作することが合理的または共通である事情があるので、この文書では、クライアントとサーバーの両方で一定の要件を置きます。
Except where stated otherwise, a client MAY use pipelining. That is, it may send a command before receiving the response for the previous command. The server MUST allow pipelining and MUST NOT throw away any text received after a command. Irrespective of whether pipelining is used, the server MUST process commands in the order they are sent.
特に明記しない場合を除いて、クライアントはパイプラインを使用するかもしれません。つまり、それは前のコマンドに対する応答を受信する前にコマンドを送信することができます。サーバーは、パイプライン化を許容しなければなりませんし、コマンドの後に受け取った任意のテキストを捨ててはなりません。かかわらずパイプラインが使用されているかどうかに、サーバーは、それらが送信された順序でコマンドを処理しなければなりません。
If the specific description of a command says it "MUST NOT be pipelined", that command MUST end any pipeline of commands. That is, the client MUST NOT send any following command until it receives the CRLF at the end of the response from the command. The server MAY ignore any data received after the command and before the CRLF at the end of the response is sent to the client.
コマンドの具体的な説明は、それが「パイプライン化されてはならない」と言う場合、そのコマンドは、コマンドのいずれかのパイプラインを終了する必要があります。それは、コマンドからの応答の最後にCRLFを受信するまでつまり、クライアントは、任意の次のコマンドを送ってはいけません。サーバーは、コマンドの後やレスポンスの最後にCRLFがクライアントに送信される前に受信したデータを無視してもよい（MAY）。
The initial connection must not be part of a pipeline; that is, the client MUST NOT send any command until it receives the CRLF at the end of the greeting.
最初の接続は、パイプラインの一部であってはなりません。それは挨拶の最後にCRLFを受信するまでつまり、クライアントは任意のコマンドを送ってはいけません。
If the client uses blocking system calls to send commands, it MUST ensure that the amount of text sent in pipelining does not cause a deadlock between transmission and reception. The amount of text involved will depend on window sizes in the transmission layer; typically, it is 4k octets for TCP. (Since the server only sends data in response to commands from the client, the converse problem does not occur.)
クライアントは、ブロッキングシステムがコマンドを送信するために呼び出して使用している場合、それはパイプラインで送られるテキストの量は、送信と受信との間のデッドロックが発生しないことを保証しなければなりません。関連するテキストの量は、透過層にウィンドウサイズに依存します。一般的に、それはTCPのために4kのオクテットです。 （サーバーが唯一のクライアントからのコマンドに応答してデータを送信するので、逆の問題は発生しません。）
Example of correct use of pipelining:
パイプラインの正しい使い方の例：
[C] GROUP misc.test [C] STAT [C] NEXT [S] 211 1234 3000234 3002322 misc.test [S] 223 3000234 <45223423@example.com> retrieved [S] 223 3000237 <668929@example.org> retrieved
[C] GROUP misc.test [C] STAT [C] NEXT [S] 211 1234 3000234 3002322 misc.test [S] 223 3000234 <45223423@example.com>検索[S] 223 3000237 <668929@example.org>検索されました
Example of incorrect use of pipelining (the MODE READER command may not be pipelined):
パイプラインの間違った使用例（MODEのREADERコマンドをパイプライン化されない場合があります）：
[C] MODE READER [C] DATE [C] NEXT [S] 200 Server ready, posting allowed [S] 223 3000237 <668929@example.org> retrieved
[C] MODE READER [C] DATE [C] NEXT [S] 200サーバの準備ができて、[S] 223 3000237 <668929@example.org>取り出させ転記
The DATE command has been thrown away by the server, so there is no 111 response to match it.
DATEコマンドは、サーバーによって捨てられているので、それに合わせて、何の111応答がありません。
NNTP is intended to transfer articles between clients and servers. For the purposes of this specification, articles are required to conform to the rules in this section, and clients and servers MUST correctly process any article received from the other that does so. Note that this requirement applies only to the contents of communications over NNTP; it does not prevent the client or server from subsequently rejecting an article for reasons of local policy. Also see Appendix A for further restrictions on the format of articles in some uses of NNTP.
NNTPは、クライアントとサーバの間で記事を転送することを意図しています。本明細書の目的のために、記事は、このセクションのルールに適合するために必要であり、クライアントとサーバは正しくそう、他から受信した任意の物品を処理しなければなりません。この要件は、NNTPを介した通信の内容にのみ適用されることに注意してください。それはその後、ローカルポリシーの理由のために記事を拒否からクライアントまたはサーバを防ぐことはできません。また、NNTPのいくつかの用途では記事の形式のさらなる制限については、付録Aを参照してください。
An article consists of two parts: the headers and the body. They are separated by a single empty line, or in other words by two consecutive CRLF pairs (if there is more than one empty line, the second and subsequent ones are part of the body). In order to meet the general requirements of NNTP, an article MUST NOT include the octet NUL, MUST NOT contain the octets LF and CR other than as part of a CRLF pair, and MUST end with a CRLF pair. This specification puts no further restrictions on the body; in particular, it MAY be empty.
ヘッダとボディ：記事は2つの部分から構成されています。それらは二つの連続CRLF組（複数の空行がある場合、第二およびその後のものが身体の一部である）によって単空行で、または他の言葉で分離されています。 NNTPの一般的な要件を満たすために、物品は、NULは、CRLFペアの一部として以外のオクテットLFとCRを含んではならない、とCRLFペアで終了する必要がありオクテットを含めることはできません。この仕様は、本体にはさらなる制限を置きません。特に、それが空であってもよいです。
The headers of an article consist of one or more header lines. Each header line consists of a header name, a colon, a space, the header content, and a CRLF, in that order. The name consists of one or more printable US-ASCII characters other than colon and, for the purposes of this specification, is not case sensitive. There MAY be more than one header line with the same name. The content MUST NOT contain CRLF; it MAY be empty. A header may be "folded"; that is, a CRLF pair may be placed before any TAB or space in the line. There MUST still be some other octet between any two CRLF pairs in a header line. (Note that folding means that the header line occupies more than one line when displayed or transmitted; nevertheless, it is still referred to as "a" header line.) The presence or absence of folding does not affect the meaning of the header line; that is, the CRLF pairs introduced by folding are not considered part of the header content. Header lines SHOULD NOT be folded before the space after the colon that follows the header name and SHOULD include at least one octet other than %x09 or %x20 between CRLF pairs. However, if an article that fails to satisfy this requirement has been received from elsewhere, clients and servers MAY transfer it to each other without re-folding it.
物品のヘッダは、一つ以上のヘッダ行から成ります。各ヘッダ行の順に、ヘッダ名、コロン、スペース、ヘッダコンテンツ、およびCRLFから成ります。名前はコロン以外の1つ以上の印刷可能なUS-ASCII文字で構成され、本明細書の目的のために、大文字と小文字の区別はありません。同じ名前を持つ複数のヘッダ行があるかもしれません。内容はCRLFを含んではいけません。それが空であってもよいです。ヘッダは、「折り畳まれ」てもよいです。つまり、CRLFペアはライン内の任意のタブまたはスペースの前に配置されてもよいです。依然としてヘッダ行内の任意の2つのCRLFペア間のいくつかの他のオクテットが存在していなければなりません。折り畳みの有無をヘッダ行の意味に影響を及ぼさない（。それにもかかわらず、それはまだ「」ヘッダ行と呼ばれ、表示または送信する際のヘッダ行が複数の行を占めることを意味する折り畳みに注意）。つまり、折り畳みによって導入CRLFペアは、ヘッダのコンテンツの一部とは見なされません。ヘッダー行は、ヘッダ名の後に続き、CRLFペア間の％のX09または％X20以外の少なくとも1つのオクテットを含むべきでコロンの後にスペース前に折り畳まれるべきではありません。この要件を満たすために失敗した記事は他の場所から受信された場合は、クライアントとサーバは、それを再折りたたみすることなく、お互いにそれを転送することができます。
The content of a header SHOULD be in UTF-8. However, if an implementation receives an article from elsewhere that uses octets in the range 128 to 255 in some other manner, it MAY pass it to a client or server without modification. Therefore, implementations MUST be prepared to receive such headers, and data derived from them (e.g., in the responses from the OVER command, Section 8.3), and MUST NOT assume that they are always UTF-8. Any external processing of those headers, including identifying the encoding used, is outside the scope of this document.
ヘッダの内容は、UTF-8でなければなりません。実装は他のいくつかの方法で、255までの範囲128のオクテットを使用して他の場所からの記事を受信した場合しかし、それは変更せずに、クライアントまたはサーバにそれを渡すことができます。したがって、実装は、そのようなヘッダを受信するように準備しなければなりません、そしてデータがそれらに由来する（例えば、オーバーコマンド、セクション8.3からの応答で）、そしてそれらは常にUTF-8であると仮定してはいけません。使用される符号化を特定するものを含むヘッダーの外部処理は、この文書の範囲外です。
Each article MUST have a unique message-id; two articles offered by an NNTP server MUST NOT have the same message-id. For the purposes of this specification, message-ids are opaque strings that MUST meet the following requirements:
各記事は、ユニークなメッセージIDを持っていなければなりません。 NNTPサーバが提供する2つの記事は、同じメッセージIDを持つことはできません。本明細書の目的のために、メッセージのIDは、次の要件を満たす必要があり、不透明な文字列です。
o A message-id MUST begin with "<", end with ">", and MUST NOT contain the latter except at the end.
OメッセージIDが「<」と、終了「>」で始まる必要があり、そして最後を除いて後者を含んではなりません。
o A message-id MUST be between 3 and 250 octets in length.
OメッセージIDは、長さが3と250オクテットの間でなければなりません。
o A message-id MUST NOT contain octets other than printable US-ASCII characters.
OメッセージIDは、印刷可能なUS-ASCII文字以外のオクテットを含んではなりません。
Two message-ids are the same if and only if they consist of the same sequence of octets.
2つのメッセージ-IDがあれば同じであり、彼らはオクテットの同じ配列からなる場合にのみ。
This specification does not describe how the message-id of an article is determined. If the server does not have any way to determine a message-id from the article itself, it MUST synthesize one (this specification does not require that the article be changed as a result). See also Appendix A.2.
この仕様は、記事のメッセージIDを決定する方法については説明しません。サーバは、物品自体からメッセージIDを決定する方法を持っていない場合、これは、1つの（本明細書は、物品が結果として変更されることを必要としない）を合成しなければなりません。また、付録A.2を参照してください。
The WILDMAT format described here is based on the version first developed by Rich Salz [SALZ1992], which was in turn derived from 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.
ここで説明するWILDMATフォーマットが最初のターンでUNIXで使用される形式から派生したリッチ・サルズ[SALZ1992]、によって開発されたバージョンに基づいてファイル名を明確にするためのコマンドを「見つけます」。これは、UNIXシェルはファイル名と一致し、同様にパターンの照合に均一なメカニズムを提供するために開発されました。
A wildmat is described by the following ABNF [RFC4234] syntax, which is an extract of that in Section 9.8.
WILDMATはセクション9.8におけるその抽出物である、以下のABNF [RFC4234]シンタックスで記述されています。
wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) wildmat-pattern = 1*wildmat-item wildmat-item = wildmat-exact / wildmat-wild wildmat-exact = %x22-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E / UTF8-non-ascii ; exclude ! * , ? [ \ ] wildmat-wild = "*" / "?"
WILDMAT = WILDMATパターン*（ "" [ "！"] WILDMATパターン）WILDMATパターン= 1 * WILDMAT項目WILDMAT項目= WILDMAT-厳密/ WILDMAT野生WILDMAT-正確=％x22-29 /％X2B /％x2D-3E /％x40-5A /％x5E-7E / UTF8非ASCII。除外！ *、？ [\] WILDMAT-野生= "*" / "？"
Note: the characters ",", "\", "[", and "]" are not allowed in wildmats, while * and ? are always wildcards. This should not be a problem, since these characters cannot occur in newsgroup names, which is the only current use of wildmats. Backslash is commonly used to suppress the special meaning of characters, whereas brackets are used to introduce sets. However, these usages are not universal, and interpretation of these characters in the context of UTF-8 strings is potentially complex and differs from existing practice, so they were omitted from this specification. A future extension to this specification may provide semantics for these characters.
注：文字は ""、 "\"、 "[" と "]" しばらく*、wildmatsに許可されていませんか？ワイルドカードは常にあります。これらの文字はwildmatsの現時点での唯一の使用であるニュースグループ名で起こることができないので、これは問題になることはありません。ブラケットがセットを導入するために使用されているのに対し、バックスラッシュは、一般的に、文字の特別な意味を抑制するために使用されます。しかし、これらの用途は普遍的ではない、とUTF-8文字列のコンテキストでこれらの文字の解釈は、潜在的に複雑で、既存の慣行とは異なり、ので、彼らはこの仕様書から除外されました。この仕様への将来の拡張には、これらの文字のためのセマンティクスを提供することができます。
A wildmat is tested against a string and either matches or does not match. To do this, each constituent <wildmat-pattern> is matched against the string, and the rightmost pattern that matches is identified. If that <wildmat-pattern> is not preceded with "!", the whole wildmat matches. If it is preceded by "!", or if no <wildmat-pattern> matches, the whole wildmat does not match.
WILDMATは、文字列のいずれかの試合に対してテストされるか、一致していません。これを行うには、各構成<WILDMATパターン>は、文字列と照合され、一致すると右端のパターンが識別されます。その<WILDMATパターン>はで始まるされていない場合は、「！」、全体WILDMATは一致します。それは、「！」が先行している、あるいは全く<WILDMATパターン>が一致しない場合は、全体WILDMATは一致しない場合。
For example, consider the wildmat "a*,!*b,*c*":
例えば、WILDMAT "！*、* B、* C *" と考えてみます。
o The string "aaa" matches because the rightmost match is with "a*".
右端の試合は「*」であるので、Oの文字列「AAA」は一致します。
o The string "abb" does not match because the rightmost match is with "*b".
右端の試合は「* bの」であるため、文字列「ABB」oを一致していません。
o The string "ccb" matches because the rightmost match is with "*c*".
右端の試合は「* Cは*」であるので、Oの文字列「CCB」は一致します。
o The string "xxx" does not match because no <wildmat-pattern> matches.
何の<WILDMATパターン>が一致しないので、Oの文字列「xxx」は一致していません。
A <wildmat-pattern> matches a string if the string can be broken into components, each of which matches the corresponding <wildmat-item> in the pattern. The matches must be in the same order, and the whole string must be used in the match. The pattern is "anchored"; that is, the first and last characters in the string must match the first and last item, respectively (unless that item is an asterisk matching zero characters).
文字列がパターンに対応する<WILDMAT項目>を一致その各々は、構成要素に分解することができれば、<WILDMATパターン>は、文字列と一致します。マッチは同じ順序である必要があり、文字列全体が試合で使用する必要があります。パターンは「アンカー」です。つまり、文字列の最初と最後の文字は最初と最後の項目、それぞれ一致している必要があり（その項目はゼロ文字に一致するアスタリスクでない限り）。
A <wildmat-exact> matches the same character (which may be more than one octet in UTF-8).
<WILDMAT-正確>（UTF-8に複数のオクテットであってもよい）、同じ文字にマッチします。
"?" matches exactly one character (which may be more than one octet).
"？"正確に（つ以上のオクテットでもよい）1つの文字に一致します。
"*" matches zero or more characters. It can match an empty string, but it cannot match a subsequence of a UTF-8 sequence that is not aligned to the character boundaries.
「*」はゼロ以上の文字に一致します。これは、空の文字列を一致させることができますが、それは文字境界にアラインされていないUTF-8シーケンスのサブシーケンスを一致させることはできません。
An NNTP server or extension MAY extend the syntax or semantics of wildmats provided that all wildmats that meet the requirements of Section 4.1 have the meaning ascribed to them by Section 4.2. Future editions of this document may also extend wildmats.
NNTPサーバまたは拡張子がwildmatsの構文や意味論はセクション4.1の要件を満たすすべてのwildmatsは、4.2節で彼らに帰する意味を有することを条件とする延長することができます。このドキュメントの将来の版もwildmatsを延長することができます。
In these examples, $ and @ are used to represent the two octets %xC2 and %xA3, respectively; $@ is thus the UTF-8 encoding for the pound sterling symbol, shown as # in the descriptions.
これらの例では、$や@はそれぞれ、2つのオクテット％のXC2と％XA3を表すために使用されています。 $ @をため、説明に＃として示さポンド記号、のためのUTF-8エンコーディングです。
Wildmat Description of strings that match abc The one string "abc" abc,def The two strings "abc" and "def" $@ The one character string "#" a* Any string that begins with "a" a*b Any string that begins with "a" and ends with "b" a*,*b Any string that begins with "a" or ends with "b" a*,!*b Any string that begins with "a" and does not end with "b" a*,!*b,c* Any string that begins with "a" and does not end with "b", and any string that begins with "c" no matter what it ends with a*,c*,!*b Any string that begins with "a" or "c" and does not end with "b" ?a* Any string with "a" as its second character ??a* Any string with "a" as its third character *a? Any string with "a" as its penultimate character *a?? Any string with "a" as its antepenultimate character
WILDMAT ABC 1つの文字列「ABC」ABC、二つの文字列defは「abc」が一致する文字列の記述と一つの文字列@「DEF」$「＃」*任意の文字列B「」*で始まる任意の文字列それは「」で始まるまたは「B」で終わる任意の文字列b *の「」で始まり、「B」*、で終わる*、！*「」とで終わらないで始まる任意の文字列B 「B」*、！* B、C *で始まる任意の文字列「a」と「b」、および関係なく、それは*で終わるものを「C」で始まるない任意の文字列で終わっていない、C *と、 ！*「」その3番目の文字として持つ任意の文字列「」その二番目の文字?? *などと任意の文字列*？「A」または「C」から始まり、「B」で終わっていない任意の文字列B *？ 「」*その最後から二番目の文字として持つ任意の文字列？ 「」としての終わりから3番目の文字と任意の文字列
This command MUST NOT be pipelined.
このコマンドは、パイプライン化されてはなりません。
Responses [1] 200 Service available, posting allowed 201 Service available, posting prohibited 400 Service temporarily unavailable [2] 502 Service permanently unavailable [2]
応答は、[1] 200サービス利用できる、転記が転記が400サービスを禁止し、201サービスが利用許可一時的に利用できない[2] 502サービス永久利用できない[2]
[1] These are the only valid response codes for the initial greeting; the server MUST not return any other generic response code.
[1]これらは、最初の挨拶のための唯一の有効な応答コードです。サーバーは、他の一般的な応答コードを返してはいけません。
[2] Following a 400 or 502 response, the server MUST immediately close the connection.
[2] 400または502応答に続いて、サーバは直ちに接続を閉じる必要があります。
There is no command presented by the client upon initial connection to the server. The server MUST present an appropriate response code as a greeting to the client. This response informs the client whether service is available and whether the client is permitted to post.
サーバーへの初期接続時にクライアントが提示するコマンドはありません。サーバーは、クライアントへの挨拶として、適切な応答コードを提示しなければなりません。この応答は、サービスが利用可能かどうか、クライアントがポストを許可されているかどうかをクライアントに通知します。
If the server will accept further commands from the client including POST, the server MUST present a 200 greeting code. If the server will accept further commands from the client, but the client is not authorized to post articles using the POST command, the server MUST present a 201 greeting code.
サーバがPOSTを含むクライアントからのさらなるコマンドを受け入れる場合、サーバは200グリーティングコードを提示しなければなりません。サーバはクライアントからのさらなるコマンドを受け付けますが、クライアントはPOSTコマンドを使用して記事を投稿を許可されていない場合、サーバーは201グリーティングコードを提示しなければなりません。
Otherwise, the server MUST present a 400 or 502 greeting code and then immediately close the connection. 400 SHOULD be used if the issue is only temporary (for example, because of load) and the client can expect to be able to connect successfully at some point in the future without making any changes. 502 MUST be used if the client is not permitted under any circumstances to interact with the server, and MAY be used if the server has insufficient information to determine whether the issue is temporary or permanent.
そうでない場合、サーバは400または502グリーティングコードを提示する必要があり、その後、直ちに接続を閉じます。問題は、（高負荷のために、例えば）のみ一時的なものであれば400を使用する必要があり、クライアントは変更を加えずに、将来のある時点で正常に接続できることを期待することができます。 502は、クライアントがサーバーと対話するために、どのような状況の下で許可されていない場合に使用されなければならない、とサーバは、問題が一時的または恒久的であるかどうかを判断するのに十分な情報を持っている場合は使用されるかもしれません。
Note: the distinction between the 200 and 201 response codes has turned out in practice to be insufficient; for example, some servers do not allow posting until the client has authenticated, while other clients assume that a 201 response means that posting will never be possible even after authentication. Therefore, clients SHOULD use the CAPABILITIES command (Section 5.2) rather than rely on this response.
注：200と201応答コードとの間の区別が不十分であることが実際に判明しました。クライアントが認証されるまで、他のクライアントは201応答がポストにも認証後に可能になることはありませんことを意味していることを前提としながら、例えば、いくつかのサーバは、投稿を許可していません。そのため、クライアントは、capabilitiesコマンド（5.2節）を使用するのではなく、この応答に依存しているべきです。
Example of a normal connection from an authorized client that then terminates the session (see Section 5.4):
その後、セッションを終了し、許可クライアントからの通常の接続の例（5.4節を参照してください）：
[Initial connection set-up completed.] [S] 200 NNTP Service Ready, posting permitted [C] QUIT [S] 205 NNTP Service exits normally [Server closes connection.]
[初期接続セットアップが完了しました。] [S] 200 NNTPサービスの準備は、許可され、[C]を掲載[S] 205 NNTPサービスが正常に終了QUIT [サーバーが接続を閉じます。]
Example of a normal connection from an authorized client that is not permitted to post, which also immediately terminates the session:
また、すぐにセッションを終了投稿することが許可されていない認可クライアントからの正常な接続の例：
[Initial connection set-up completed.] [S] 201 NNTP Service Ready, posting prohibited [C] QUIT [S] 205 NNTP Service exits normally [Server closes connection.]
[初期接続セットアップが完了しました。] [S] 201 NNTPサービスの準備は、禁止[C]を掲載[S] 205 NNTPサービスが正常に終了QUIT [サーバーが接続を閉じます。]
Example of a normal connection from an unauthorized client:
不正なクライアントからの正常な接続の例：
[Initial connection set-up completed.] [S] 502 NNTP Service permanently unavailable [Server closes connection.]
[初期接続セットアップが完了しました。] [S] 502 NNTPサービス恒久的に利用できません[サーバーが接続を閉じます。]
Example of a connection from a client if the server is unable to provide service:
サーバーがサービスを提供することができない場合は、クライアントからの接続の例：
[Initial connection set-up completed.] [S] 400 NNTP Service temporarily unavailable [Server closes connection.]
[初期接続セットアップが完了しました。] [S] 400 NNTPサービス一時的に利用できない[サーバーが接続を閉じます。]
This command is mandatory.
このコマンドは必須です。
Syntax CAPABILITIES [keyword]
構文ケーパビリティ[キーワード]
Responses 101 Capability list follows (multi-line)
応答101能力リストは、以下の（マルチライン）
Parameters keyword additional feature, see description
パラメータは、追加の機能をキーワード、説明を参照してください
The CAPABILITIES command allows a client to determine the capabilities of the server at any given time.
capabilitiesコマンドは、クライアントが任意の時点で、サーバーの能力を決定することができます。
This command MAY be issued at any time; the server MUST NOT require it to be issued in order to make use of any capability. The response generated by this command MAY change during a session because of other state information (which, in turn, may be changed by the effects of other commands or by external events). An NNTP client is only able to get the current and correct information concerning available capabilities at any point during a session by issuing a CAPABILITIES command at that point of that session and processing the response.
このコマンドはいつでも発行することができます。サーバーは、任意の機能を利用するために発行することを要求してはなりません。このコマンドによって生成された応答があるため（これは、他のコマンドの効果によって、または外部の事象によって変更されてもよい、）他の状態情報のセッション中に変更することができます。 NNTPクライアントは、そのセッションのその時点でcapabilitiesコマンドを発行し、応答を処理することにより、セッション中の任意の時点で利用可能な機能について、現在、正しい情報を得ることができるだけです。
The capability list is returned as a multi-line data block following the 101 response code. Each capability is described by a separate capability line. The server MUST NOT list the same capability twice in the response, even with different arguments. Except that the VERSION capability MUST be the first line, the order in which the capability lines appears is not significant; the server need not even consistently return the same order.
能力リストは、101応答コード次のマルチラインのデータブロックとして返されます。各機能は別個能力ラインにより記述されます。サーバーは、異なる引数を指定して、反応して二度同じ機能をリストしてはなりません。 VERSION能力は最初の行でなければならないことを除いて、機能ラインが表示される順序は重要ではありません。サーバーでも一貫して同じ順序を返す必要はありません。
While some capabilities are likely to be always available or never available, others (notably extensions) will appear and disappear depending on server state changes within the session or on external events between sessions. An NNTP client MAY cache the results of this command, but MUST NOT rely on the correctness of any cached results, whether from earlier in this session or from a previous session, MUST cope gracefully with the cached status being out of date, and SHOULD (if caching results) provide a way to force the cached information to be refreshed. Furthermore, a client MUST NOT use cached results in relation to security, privacy, and authentication extensions. See Section 12.6 for further discussion of this topic.
いくつかの機能が常に利用または利用可能決して可能性が高いですが、他の人（特に拡張子）が表示され、セッション内またはセッション間の外部イベントでのサーバの状態変化に応じて、表示されなくなります。 NNTPクライアントは、このコマンドの結果をキャッシュするかもしれが、このセッションでは、以前から、または前のセッションからかどうか、任意のキャッシュされた結果の正しさに頼ってはならない、キャッシュされた状態が最新のもので優雅に対処しなければならない、とSHOULD（キャッシングの結果）がキャッシュされた情報を強制する方法を提供する場合に更新されます。さらに、クライアントは、セキュリティ、プライバシー、および認証の拡張機能に関連して、キャッシュされた結果を使用してはなりません。このトピックについてのさらなる議論については、セクション12.6を参照してください。
The keyword argument is not used by this specification. It is provided so that extensions or revisions to this specification can include extra features for this command without requiring the CAPABILITIES command to be used twice (once to determine if the extra features are available, and a second time to make use of them). If the server does not recognise the argument (and it is a keyword), it MUST respond with the 101 response code as if the argument had been omitted. If an argument is provided that the server does recognise, it MAY use the 101 response code or MAY use some other response code (which will be defined in the specification of that feature). If the argument is not a keyword, the 501 generic response code MUST be returned. The server MUST NOT generate any other response code to the CAPABILITIES command.
キーワード引数は、本明細書で使用されていません。この仕様の拡張や修正が能力を必要とせずに、このコマンドの追加機能を含めることができるようにそれは2回使用するコマンド（余分な機能が利用可能かどうかを決定するために、一度、それらを利用するために2回目）に提供されます。サーバーが引数を認識しない（とそれがキーワードである）場合には、引数が省略されたかのように、それは101応答コードで応じなければなりません。引数は、サーバが認識しないことが提供される場合、それは101応答コードを使用してもよいし、（その機能の仕様で定義される）いくつかの他のレスポンスコードを使用するかもしれません。引数がキーワードでない場合は、501の一般的な応答コードを返さなければなりません。サーバーは、capabilitiesコマンドに他の応答コードを生成してはなりません。
Example of a minimal response (a read-only server):
最小限の応答（読み取り専用サーバー）の例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS [S] .
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS [S]。
Example of a response from a server that has a range of facilities and that also describes itself:
施設の範囲を有し、それはそれ自体を記述し、サーバからの応答の例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] IHAVE [S] POST [S] NEWNEWS [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES OVERVIEW.FMT [S] IMPLEMENTATION INN 4.2 2004-12-25 [S] OVER MSGID [S] STREAMING [S] XSECRET [S] .
[C]は、CAPABILITIES [S] 101の能力リスト：[S]は、バージョン2 [S] READER [S] IHAVE [S] POST [S] NEWNEWS [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES OVERVIEW.FMT [S] IMPLEMENTATION INN 4.2 2004年12月25日[S] OVER MSGID [S] STREAMING [S] XSECRET [S]。
Example of a server that supports more than one version of NNTP:
NNTPの複数のバージョンをサポートするサーバーの例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 3 [S] READER [S] LIST ACTIVE NEWSGROUPS [S] .
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 3 [S] READER [S] LIST ACTIVE NEWSGROUPS [S]。
Example of a client attempting to use a feature of the CAPABILITIES command that the server does not support:
機能は、サーバーがサポートしていないことを、コマンドの機能を使用しようとしているクライアントの例：
[C] CAPABILITIES AUTOUPDATE [S] 101 Capability list: [S] VERSION 2 [S] READER [S] IHAVE [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT HEADERS [S] OVER MSGID [S] HDR [S] NEWNEWS [S] .
[C] CAPABILITIESのAUTOUPDATE [S] 101の能力リスト：[S] VERSION 2 [S]読者]いる[A] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT HEADERS [S] OVER MSGID [S] HDR [S] NEW NEWS [S] 。
Indicating capability: MODE-READER
能力を示す：MODE-READER
This command MUST NOT be pipelined.
このコマンドは、パイプライン化されてはなりません。
Syntax MODE READER
構文MODEリーダー
Responses 200 Posting allowed 201 Posting prohibited 502 Reading service permanently unavailable [1]
応答は、200転記201転記が禁止許可502読書サービス永久的に利用できない[1]
[1] Following a 502 response the server MUST immediately close the connection.
[1] 502応答サーバは直ちに接続を閉じる必要があり続い。
The MODE READER command instructs a mode-switching server to switch modes, as described in Section 3.4.2.
MODEリーダコマンドは、セクション3.4.2で説明したように、モードを切り替えるモード切り替えサーバに指示します。
If the server is mode-switching, it switches from its transit mode to its reader mode, indicating this by changing the capability list accordingly. It MUST then return a 200 or 201 response with the same meaning as for the initial greeting (as described in Section 5.1.1). Note that the response need not be the same as that presented during the initial greeting. The client MUST NOT issue MODE READER more than once in a session or after any security or privacy commands are issued. When the MODE READER command is issued, the server MAY reset its state to that immediately after the initial connection before switching mode.
サーバは、モード切り替えである場合、それに応じて機能リストを変更することによってこのことを示す、その走行モードから、そのリーダーモードに切り替えます。その後、（セクション5.1.1で説明したように）最初の挨拶と同じ意味を持つ200または201応答を返さなければなりません。応答は、最初の挨拶の際に提示したものと同じである必要はないことに注意してください。クライアントはセッション中または任意のセキュリティやプライバシーのコマンドが発行された後、何度もMODEリーダーよりを発行してはいけません。 MODEのREADERコマンドが発行されると、サーバーはすぐにモードを切り替える前に、最初の接続後にそれにその状態をリセットするかもしれません。
If the server is not mode-switching, then the following apply:
サーバはモード切替でない場合は、次が適用されます。
o If it advertises the READER capability, it MUST return a 200 or 201 response with the same meaning as for the initial greeting; in this case, the command MUST NOT affect the server state in any way.
それはリーダー能力をアドバタイズする場合、O、それは最初の挨拶と同じ意味を持つ200または201応答を返さなければなりません。この場合には、このコマンドはどのような方法で、サーバーの状態に影響してはいけません。
o If it does not advertise the READER capability, it MUST return a 502 response and then immediately close the connection.
それがREADERの機能をアドバタイズしない場合は、O、それは502応答を返した後、すぐに接続を閉じる必要があります。
Example of use of the MODE READER command on a transit-only server (which therefore does not providing reading facilities):
（したがって、読み出し機能を提供しない）トランジット専用サーバのMODE READERコマンドの使用例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] IHAVE [S] . [C] MODE READER [S] 502 Transit service only [Server closes connection.]
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] IHAVE [S]。 [C] MODEリーダ[S]のみ502トランジットサービス[サーバが接続を閉じます。]
Example of use of the MODE READER command on a server that provides reading facilities:
読み取り機能を提供するサーバのMODE READERコマンドの使用例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS [S] . [C] MODE READER [S] 200 Reader mode, posting permitted [C] IHAVE <i.am.an.article.you.have@example.com> [S] 500 Permission denied [C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS [S]。 [C] MODEリーダ[S] 200リーダモード、許可転記[C] IHAVE <i.am.an.article.you.have@example.com> [S] 500許可拒否[C] GROUP misc.test [S ] 211 1234 3000234 3002322 misc.test
Note that in both of these situations, the client SHOULD NOT use MODE READER.
これらの状況の両方で、クライアントは、MODEリーダーを使用するべきではないことに注意してください。
Example of use of the MODE READER command on a mode-switching server:
モード切替サーバーのMODE READERコマンドの使用例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] IHAVE [S] MODE-READER [S] . [C] MODE READER [S] 200 Reader mode, posting permitted [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] NEWNEWS [S] LIST ACTIVE NEWSGROUPS [S] STARTTLS [S] .
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] IHAVE [S] MODE-READER [S]。 [C] MODEリーダ[S] 200リーダモード、許可[C]の機能を投稿[S] 101の能力リスト：[S] VERSION 2 [S] READER [S] NEWNEWS [S] LIST ACTIVE NEWSGROUPS [S] STARTTLS [S ]。
In this case, the server offers (but does not require) TLS privacy in its reading mode but not in its transit mode.
この場合、サーバの提供は、その読み取りモードではなく、その輸送モードでのTLSのプライバシーを（必須ではありません）。
Example of use of the MODE READER command where the client is not permitted to post:
クライアントがポストに許可されていないのMODE READERコマンドの使用例：
[C] MODE READER [S] 201 NNTP Service Ready, posting prohibited
[C] MODEリーダー[S] 201 NNTPサービスの準備、禁止投稿
This command is mandatory.
このコマンドは必須です。
Syntax QUIT
構文は、QUIT
Responses 205 Connection closing
応答205の接続を閉じます
The client uses the QUIT command to terminate the session. The server MUST acknowledge the QUIT command and then close the connection to the client. This is the preferred method for a client to indicate that it has finished all of its transactions with the NNTP server.
クライアントがセッションを終了するQUITコマンドを使用しています。サーバーは、QUITコマンドを確認し、クライアントへの接続を閉じる必要があります。これは、NNTPサーバーとのすべてのトランザクションを完了したことを示すために、クライアントのための好ましい方法です。
If a client simply disconnects (or if the connection times out or some other fault occurs), the server MUST gracefully cease its attempts to service the client, disconnecting from its end if necessary.
クライアントは、単に（または接続がタイムアウトまたはその他の障害が発生した場合に）切断した場合、サーバーは正常、必要に応じてその端から切り離し、クライアントにサービスを提供するという試みを中止しなければなりません。
The server MUST NOT generate any response code to the QUIT command other than 205 or, if any arguments are provided, 501.
いずれかの引数が提供されている場合、サーバーは501、205以外のQUITコマンドへの応答コードを生成したりしてはなりません。
[C] QUIT
[S] 205 closing connection
[Server closes connection.]
News-reading clients have available a variety of mechanisms to retrieve articles via NNTP. The news articles are stored and indexed using three types of keys. The first type of key is the message-id of an article and is globally unique. The second type of key is composed of a newsgroup name and an article number within that newsgroup. On a particular server, there MUST only be one article with a given number within any newsgroup, and an article MUST NOT have two different numbers in the same newsgroup. An article can be cross-posted to multiple newsgroups, so there may be multiple keys that point to the same article on the same server; these MAY have different numbers in each newsgroup. However, this type of key is not required to be globally unique, so the same key MAY refer to different articles on different servers. (Note that the terms "group" and "newsgroup" are equivalent.)
ニュース読み取りクライアントがNNTP経由で記事を検索するためのさまざまなメカニズムを用意して。ニュース記事は、キーの3種類を使用して格納し、インデックス化されています。キーの第一のタイプは、物品のメッセージIDであり、グローバルに一意です。キーの第二のタイプは、ニュースグループ名とそのニュースグループ内の文書番号から構成されています。特定のサーバーでは、唯一の任意のニュースグループ内の指定された番号の一品がでなければならない、と記事では、同じニュースグループに二つの異なる数字を持ってはいけません。物品は、複数のニュースグループにクロスポストすることができるので、同じサーバー上の同じ物品を指す複数のキーがあってもよいです。これらは、各ニュースグループで異なる番号を持っているかもしれません。しかし、このタイプのキーは、グローバルに一意である必要はないので、同じキーが異なるサーバー上の別の記事を参照してもよいです。 （用語「基」および「ニュースグループ」と等価であることに注意してください。）
The final type of key is the arrival timestamp, giving the time that the article arrived at the server. The server MUST ensure that article numbers are issued in order of arrival timestamp; that is, articles arriving later MUST have higher numbers than those that arrive earlier. The server SHOULD allocate the next sequential unused number to each new article.
キーの最後のタイプは、記事がサーバーに到着した時間を与え、到着タイムスタンプです。サーバーは、その記事番号が到着タイムスタンプの順で発行されていることを確認しなければなりません。つまり、後から到着した記事は、以前に到着するものよりも高い数値を持っていなければなりません。サーバは、それぞれの新しい記事へ次の連続未使用の番号を割り当てる必要があります。
Article numbers MUST lie between 1 and 2,147,483,647, inclusive. The client and server MAY use leading zeroes in specifying article numbers but MUST NOT use more than 16 digits. In some situations, the value zero replaces an article number to show some special situation.
資料番号は、包括、1〜2,147,483,647の間になければなりません。クライアントとサーバは記事番号を指定する際に先行ゼロを使うかもしれませんが、16個の以上の数字を使用してはなりません。いくつかの状況では、値ゼロは、いくつかの特別な状況を示すための資料番号を置き換えます。
Note that it is likely that the article number limit of 2,147,483,647 will be increased by a future revision or extension to this specification. While servers MUST NOT send article numbers greater than this current limit, client and server developers are advised to use internal structures and datatypes capable of handling larger values in anticipation of such a change.
2,147,483,647の資料番号の制限はこの仕様に将来のリビジョンまたは拡張によって増加される可能性があることに注意してください。サーバはこの電流制限値よりも大きいの資料番号を送ってはいけませんが、クライアントとサーバの開発者は、このような変更を見越して、より大きな値を処理できる内部構造とデータ型を使用することをお勧めします。
The following commands are used to set the "currently selected newsgroup" and the "current article number", which are used by various commands. At the start of an NNTP session, both of these values are set to the special value "invalid".
次のコマンドは、様々なコマンドが使用され、「現在選択されているニュースグループ」と「現在の文書番号を」設定するために使用されています。 NNTPセッションの開始時に、これらの値の両方を「無効」特別な値に設定されています。
Indicating capability: READER
示す機能：READER
Syntax GROUP group
構文GROUPグループ
Responses 211 number low high group Group successfully selected 411 No such newsgroup
回答211数低高グループのグループが成功した411は、このようなニュースグループ選択しました
Parameters group Name of newsgroup number Estimated number of articles in the group low Reported low water mark high Reported high water mark
グループの低報告低ウォーターマーク内の記事のニュースグループ数推定数のパラメータグループの名前は、高いハイウォーターマークを報告します
The GROUP command selects a newsgroup as the currently selected newsgroup and returns summary information about it.
GROUPコマンドは、現在選択されているニュースグループとしてニュースグループを選択し、それについての要約情報を返します。
The required argument is the name of the newsgroup to be selected (e.g., "news.software.nntp"). A list of valid newsgroups may be obtained by using the LIST ACTIVE command (see Section 7.6.3).
必要な引数は、ニュースグループの名前（例えば、「news.software.nntp」）を選択します。有効なニュースグループの一覧がLIST ACTIVEコマンドを使用することによって得ることができる（セクション7.6.3を参照してください）。
The successful selection response will return the article numbers of the first and last articles in the group at the moment of selection (these numbers are referred to as the "reported low water mark" and the "reported high water mark") and an estimate of the number of articles in the group currently available.
成功した選択応答は、との推定値（これらの数値は、「低水位マークを報告した」と「ハイウォーターマークを報告した」とも呼ばれる）を選択した瞬間に、グループ内の最初と最後の記事の記事番号を返します。グループ内の記事の数は、現在入手可能。
If the group is not empty, the estimate MUST be at least the actual number of articles available and MUST be no greater than one more than the difference between the reported low and high water marks. (Some implementations will actually count the number of articles currently stored. Others will just subtract the low water mark from the high water mark and add one to get an estimate.)
グループが空でない場合、推定値は、利用可能な物品の少なくとも実際の数値でなければなりませんと報告低および高ウォーターマーク間の差よりも大きくない1以上でなければなりません。 （一部の実装では、実際に現在保存されている記事の数をカウントします。その他は、単に高いウォーターマークから低水位マークを減算し、推定値を得るために1が追加されます。）
If the group is empty, one of the following three situations will occur. Clients MUST accept all three cases; servers MUST NOT represent an empty group in any other way.
グループが空の場合は、以下の3つの状況のいずれかが発生します。クライアントは、すべての3つのケースを受け入れなければなりません。サーバーは、他の方法で空のグループを表現してはなりません。
o The high water mark will be one less than the low water mark, and the estimated article count will be zero. Servers SHOULD use this method to show an empty group. This is the only time that the high water mark can be less than the low water mark.
O高水位マークが低水位マークより1つ少なくなり、推定記事のカウントがゼロになります。サーバーは、空のグループを表示するには、このメソッドを使用する必要があります。これは、最高水準点が最低基準未満とすることができるという唯一の時間です。
o All three numbers will be zero.
Oすべての3つの数字がゼロになります。
o The high water mark is greater than or equal to the low water mark. The estimated article count might be zero or non-zero; if it is non-zero, the same requirements apply as for a non-empty group.
Oハイウォーターマークが低水準以上です。推定記事のカウントがゼロまたは非ゼロであるかもしれません。それが非ゼロであれば、同じ要件が非空のグループ用として適用します。
The set of articles in a group may change after the GROUP command is carried out:
GROUPコマンドが実行された後、グループ内の記事のセットが変更される場合があります。
o Articles may be removed from the group.
Oの記事をグループから除去することができます。
o Articles may be reinstated in the group with the same article number, but those articles MUST have numbers no less than the reported low water mark (note that this is a reinstatement of the previous article, not a new article reusing the number).
Oの記事は、同じ記事番号のグループに復帰することができるが、これらの記事は、（これは前の記事の復職、ない番号を再利用し、新たな記事であることに注意してください）報告低水位マークを下回らない番号を持たなければなりません。
o New articles may be added with article numbers greater than the reported high water mark. (If an article that was the one with the highest number has been removed and the high water mark has been adjusted accordingly, the next new article will not have the number one greater than the reported high water mark.)
O新しい記事が報告された高いウォーターマークよりも大きいの資料番号を添加してもよいです。 （最も高い番号のいずれかが削除されていた記事と高いウォーターマークがそれに応じて調整されている場合、次の新しい記事は数報告ハイウォーターマークよりも大きいものを持っていません）。
Except when the group is empty and all three numbers are zero, whenever a subsequent GROUP command for the same newsgroup is issued, either by the same client or a different client, the reported low water mark in the response MUST be no less than that in any previous response for that newsgroup in this session, and it SHOULD be no less than that in any previous response for that newsgroup ever sent to any client. Any failure to meet the latter condition SHOULD be transient only. The client may make use of the low water mark to remove all remembered information about articles with lower numbers, as these will never recur. This includes the situation when the high water mark is one less than the low water mark. No similar assumption can be made about the high water mark, as this can decrease if an article is removed and then increase again if it is reinstated or if new articles arrive.
グループが空で、すべての3つの数字が同じニュースグループのために、後続のGROUPコマンドが発行されるたびに、ゼロであり、どちらか同じクライアントまたは異なるクライアントによって、応答で報告された低ウォーターマークはよりも満足する必要があります場合を除き、このセッションではそのニュースグループの以前の応答、そしてそれは、これまで任意のクライアントに送信されたニュースグループの以前の応答に比べて劣らないはずです。後者の条件を満たすためにどれだけ失敗は一過性であるべきです。クライアントは、これらが再発することはありませんように、低ウォーターマークの使用は、小さい番号の記事に関するすべての学習情報を削除することがあります。ハイウォーターマークが低水位マークよりも1小さいとき、これは状況を含んでいます。いいえ同様の仮定は、これは記事が削除された場合に減少し、それが復活した場合、または新しい記事が到着した場合には再び増加することができますよう、最高水準点について行うことはできません。
When a valid group is selected by means of this command, the currently selected newsgroup MUST be set to that group, and the current article number MUST be set to the first article in the group (this applies even if the group is already the currently selected newsgroup). If an empty newsgroup is selected, the current article number is made invalid. If an invalid group is specified, the currently selected newsgroup and current article number MUST NOT be changed.
有効なグループは、このコマンドによって選択された場合、現在選択されているニュースグループは、そのグループに設定しなければならなくて、現在の記事数は、グループ内の最初の記事に設定しなければならない（これは、グループがすでに現在選択されている場合にも適用されますニュースグループ）。空のニュースグループを選択した場合、現在の資料番号を無効とされます。無効なグループが指定されている場合は、現在選択されているニュースグループや現在の資料番号を変更してはいけません。
The GROUP or LISTGROUP command (see Section 6.1.2) MUST be used by a client, and a successful response received, before any other command is used that depends on the value of the currently selected newsgroup or current article number.
GROUPまたはLISTGROUPコマンド（セクション6.1.2を参照）、クライアントによって使用されなければならない、および他のコマンドは、現在選択されているニュースグループまたは現在の文書番号の値に依存することに使用される前に、成功応答は、受信されました。
If the group specified is not available on the server, a 411 response MUST be returned.
指定されたグループがサーバー上で使用できない場合、411応答が返されなければなりません。
Example for a group known to the server:
サーバーに知られているグループの例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test
[C]グループmisc.test [S] 211 1234 3000234 3002322 misc.test
Example for a group unknown to the server:
サーバーへの未知のグループの例：
[C] GROUP example.is.sob.bradner.or.barber [S] 411 example.is.sob.bradner.or.barber is unknown
[C]グループexample.is.sob.bradner.or.barber [S] 411 example.is.sob.bradner.or.barberが未知であります
Example of an empty group using the preferred response:
好ましい応答を使用して空のグループの例：
[C] GROUP example.currently.empty.newsgroup [S] 211 0 4000 3999 example.currently.empty.newsgroup
[C]グループexample.currently.empty.newsgroup [S] 0 211 4000 3999 example.currently.empty.newsgroup
Example of an empty group using an alternative response:
代替的な応答を使用して空のグループの例：
[C] GROUP example.currently.empty.newsgroup [S] 211 0 0 0 example.currently.empty.newsgroup
[C]グループexample.currently.empty.newsgroup [S] 211 0 0 example.currently.empty.newsgroup
Example of an empty group using a different alternative response:
別の代替応答を使用して空のグループの例：
[C] GROUP example.currently.empty.newsgroup [S] 211 0 4000 4321 example.currently.empty.newsgroup
[C]グループexample.currently.empty.newsgroup [S] 0 211 4000 4321 example.currently.empty.newsgroup
Example reselecting the currently selected newsgroup:
現在選択されているニュースグループを再選択例：
[C] GROUP misc.test [S] 211 1234 234 567 misc.test [C] STAT 444 [S] 223 444 <123456@example.net> retrieved [C] GROUP misc.test [S] 211 1234 234 567 misc.test [C] STAT [S] 223 234 <different@example.net> retrieved
[C] GROUP misc.test [S] 211 1234 234 567 misc.test [C] STAT 444 [S] 223 444 <123456@example.net>取得[C] GROUP misc.test [S] 211 1234 234 567その他検索.TEST [C] STAT [S] 223 234 <different@example.net>
Indicating capability: READER
示す機能：READER
Syntax LISTGROUP [group [range]]
構文LISTGROUP [グループ[範囲]
Responses 211 number low high group Article numbers follow (multi-line) 411 No such newsgroup 412 No newsgroup selected [1]
応答211の番号低高いグループ文書番号が（マルチライン）に従う411は、このようなニュースグループ412なしニュースグループ選択した[1]
Parameters group Name of newsgroup range Range of articles to report number Estimated number of articles in the group low Reported low water mark high Reported high water mark
低ウォーターマークを報告したグループの低内の記事数推定数を報告する記事のニュースグループの範囲の範囲のパラメータグループの名前は、高いハイウォーターマークを報告します
[1] The 412 response can only occur if no group has been specified.
グループが指定されていない場合、[1] 412応答のみ起こり得ます。
The LISTGROUP command selects a newsgroup in the same manner as the GROUP command (see Section 6.1.1) but also provides a list of article numbers in the newsgroup. If no group is specified, the currently selected newsgroup is used.
LISTGROUPコマンドは、GROUPコマンド（セクション6.1.1を参照）と同様に、ニュースグループを選択するだけでなく、ニュースグループの資料番号のリストを提供します。グループが指定されていない場合は、現在選択されているニュースグループが使用されています。
On success, a list of article numbers is returned as a multi-line data block following the 211 response code (the arguments on the initial response line are the same as for the GROUP command). The list contains one number per line and is in numerical order. It lists precisely those articles that exist in the group at the moment of selection (therefore, an empty group produces an empty list). If the optional range argument is specified, only articles within the range are included in the list (therefore, the list MAY be empty even if the group is not).
成功した場合に、文書番号のリストは、211応答コード（初期応答ラインの引数がGROUPコマンドと同じである）は、以下のマルチラインのデータブロックとして返されます。リストには、1行に1つの番号が含まれており、番号順にあります。これは、選択の瞬間（それゆえ、空のグループは空のリストを生成します）で、グループ内に存在し、正確にそれらの記事が一覧表示されます。オプションの範囲引数が指定されている場合、範囲内の記事だけをリスト（グループがない場合でもので、リストが空の場合もある）に含まれています。
The range argument may be any of the following:
範囲引数は、次のいずれであってもよいです。
o An article number.
資料番号O。
o An article number followed by a dash to indicate all following.
以下のすべてを示すためにダッシュが続くの資料番号O。
o An article number followed by a dash followed by another article number.
Oの資料番号は、別の記事の番号が続くダッシュが続きます。
In the last case, if the second number is less than the first number, then the range contains no articles. Omitting the range is equivalent to the range 1- being specified.
二番目の数字は、最初の数より少ない場合、最後の場合には、その後の範囲には記事が含まれていません。範囲を省略すると、指定された範囲1-と等価です。
If the group specified is not available on the server, a 411 response MUST be returned. If no group is specified and the currently selected newsgroup is invalid, a 412 response MUST be returned.
指定されたグループがサーバー上で使用できない場合、411応答が返されなければなりません。何グループが指定されていないと、現在選択されているニュースグループが無効である場合、412応答が返されなければなりません。
Except that the group argument is optional, that a range argument can be specified, and that a multi-line data block follows the 211 response code, the LISTGROUP command is identical to the GROUP command. In particular, when successful, the command sets the current article number to the first article in the group, if any, even if this is not within the range specified by the second argument.
グループ引数が範囲引数を指定することができることは、任意であり、複数行のデータブロックは211応答コードに従うこと、LISTGROUPコマンドがGROUPコマンドと同一であることを除い。具体的には、成功した場合、コマンドは、これが2番目の引数で指定された範囲内にない場合でも、グループの最初の記事、存在する場合に、現在の文書番号を設定します。
Note that the range argument is a new feature in this specification and servers that do not support CAPABILITIES (and therefore do not conform to this specification) are unlikely to support it.
範囲引数が機能をサポートしていない（したがって、この仕様に準拠していません）この仕様書とサーバーの新機能でそれをサポートしそうにないことに注意してください。
Example of LISTGROUP being used to select a group:
LISTGROUPの例では、グループを選択するために使用されています：
[C] LISTGROUP misc.test [S] 211 2000 3000234 3002322 misc.test list follows [S] 3000234 [S] 3000237 [S] 3000238 [S] 3000239 [S] 3002322 [S] .
[C] LISTGROUP misc.test [S] 211 2000 3000234 3002322 misc.testリストは、以下の[S] 3000234 [S] 3000237 [S] 3000238 [のS] 3000239 [S] 3002322 [S]。
Example of LISTGROUP on an empty group:
空のグループにLISTGROUPの例：
[C] LISTGROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup list follows [S] .
[C] LISTGROUP example.empty.newsgroup [S] 211 0 0 example.empty.newsgroupリストは、[S]以下。
Example of LISTGROUP on a valid, currently selected newsgroup:
有効な、現在選択されているニュースグループにLISTGROUPの例：
[C] GROUP misc.test [S] 211 2000 3000234 3002322 misc.test [C] LISTGROUP [S] 211 2000 3000234 3002322 misc.test list follows [S] 3000234 [S] 3000237 [S] 3000238 [S] 3000239 [S] 3002322 [S] .
[C] GROUP misc.test [S] 211 2000 3000234 3002322 misc.test [C]がLISTGROUPは[S] 211 2000 3000234 3002322 misc.testリストは以下の[S] 3000234 [S] 3000237 [S] 3000238 [のS] 3000239 [ S] 3002322 [のS]。
Example of LISTGROUP with a range:
範囲とLISTGROUPの例：
[C] LISTGROUP misc.test 3000238-3000248 [S] 211 2000 3000234 3002322 misc.test list follows [S] 3000238 [S] 3000239 [S] .
[C] LISTGROUP misc.test 3000238-3000248 [S] 211 2000 3000234 3002322 misc.testリストは、以下の[S] 3000238 [S] 3000239 [S]。
Example of LISTGROUP with an empty range:
空の範囲とLISTGROUPの例：
[C] LISTGROUP misc.test 12345678- [S] 211 2000 3000234 3002322 misc.test list follows [S] .
[C] LISTGROUP misc.test 12345678- [S] 211 2000 3000234 3002322 misc.testリストは、[S]以下。
Example of LISTGROUP with an invalid range:
無効な範囲でLISTGROUPの例：
[C] LISTGROUP misc.test 9999-111 [S] 211 2000 3000234 3002322 misc.test list follows [S] .
[C] LISTGROUP misc.test 9999-111【のS] 211 2000 3000234 3002322 misc.testリストは、[S]以下。
Indicating capability: READER
示す機能：READER
Syntax LAST
構文LAST
Responses 223 n message-id Article found 412 No newsgroup selected 420 Current article number is invalid 422 No previous article in this group
223 NメッセージID物品が412見出さ応答なしニュースグループは420現在の記事数がこのグループの以前の記事無効422ではない選択されていません
Parameters n Article number message-id Article message-id
パラメータn条数のメッセージIDの記事のメッセージID
If the currently selected newsgroup is valid, the current article number MUST be set to the previous article in that newsgroup (that is, the highest existing article number less than the current article number). If successful, a response indicating the new current article number and the message-id of that article MUST be returned. No article text is sent in response to this command.
現在選択されているニュースグループが有効な場合は、現在の記事数は、そのニュースグループの前回の記事（つまり、現在の記事の数より少ない最高の既存の資料番号である）に設定しなければなりません。成功した場合、新たな現在の文書番号とその記事のメッセージIDを示す応答が返されなければなりません。いいえ記事のテキストは、このコマンドに応答して送信されません。
There MAY be no previous article in the group, although the current article number is not the reported low water mark. There MUST NOT be a previous article when the current article number is the reported low water mark.
現在の記事数が報告された低ウォーターマークはありませんが、グループには、以前の記事ではないかもしれません。現在の記事数が報告された低ウォーターマークであるとき、前の記事があってはなりません。
Because articles can be removed and added, the results of multiple LAST and NEXT commands MAY not be consistent over the life of a particular NNTP session.
記事を削除して追加することができるため、複数のLASTとNEXTコマンドの結果は、特定のNNTPセッションの期間にわたって一貫しないかもしれません。
If the current article number is already the first article of the newsgroup, a 422 response MUST be returned. If the current article number is invalid, a 420 response MUST be returned. If the currently selected newsgroup is invalid, a 412 response MUST be returned. In all three cases, the currently selected newsgroup and current article number MUST NOT be altered.
現在の文書番号がすでにニュースグループの最初の記事であれば、422応答が返されなければなりません。現在の資料番号が無効である場合、420応答が返されなければなりません。現在選択されているニュースグループが無効である場合、412応答が返されなければなりません。すべての3つのケースでは、現在選択されているニュースグループや現在の資料番号を変更しないでください。
Example of a successful article retrieval using LAST:
LASTを使用して成功した記事検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] NEXT [S] 223 3000237 <668929@example.org> retrieved [C] LAST [S] 223 3000234 <45223423@example.com> retrieved
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] NEXT [S] 223 3000237 <668929@example.org>取得[C] LAST [S] 223 3000234 <45223423@example.com>検索されました
Example of an attempt to retrieve an article without having selected a group (via the GROUP command) first:
第一（GROUPコマンドによって）グループを選択せずに物品を取得しようとする試みの例：
[Assumes currently selected newsgroup is invalid.] [C] LAST [S] 412 no newsgroup selected
[現在選択されているニュースグループが無効であると仮定。] [C] LAST [S] 412ないニュースグループ選択
Example of an attempt to retrieve an article using the LAST command when the current article number is that of the first article in the group:
現在の記事数は、グループ内の最初の記事のものであるとき、LASTコマンドを使用して記事を取得しようとする試みの例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] LAST [S] 422 No previous article to retrieve
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] LAST [S] 422取得する以前の記事
Example of an attempt to retrieve an article using the LAST command when the currently selected newsgroup is empty:
現在選択されているニュースグループが空の場合LASTコマンドを使用して記事を取得しようとする試みの例：
[C] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] LAST [S] 420 No current article selected
[C]グループexample.empty.newsgroup [S] 211 0 0 example.empty.newsgroup [C] LAST [S] 420が選択されていません現在の記事
Indicating capability: READER
示す機能：READER
Syntax NEXT
構文NEXT
Responses 223 n message-id Article found 412 No newsgroup selected 420 Current article number is invalid 421 No next article in this group
応答223 NメッセージID物品は412なしニュースグループは420現在の記事数がこのグループの421なし次の記事無効でない選択が見つかりません
Parameters n Article number message-id Article message-id
パラメータn条数のメッセージIDの記事のメッセージID
If the currently selected newsgroup is valid, the current article number MUST be set to the next article in that newsgroup (that is, the lowest existing article number greater than the current article number). If successful, a response indicating the new current article number and the message-id of that article MUST be returned. No article text is sent in response to this command.
現在選択されているニュースグループが有効である場合、現在の文書番号（すなわち、現在の記事の数よりも大きい最小の既存の資料番号である）そのニュースグループ内の次の記事に設定しなければなりません。成功した場合、新たな現在の文書番号とその記事のメッセージIDを示す応答が返されなければなりません。いいえ記事のテキストは、このコマンドに応答して送信されません。
If the current article number is already the last article of the newsgroup, a 421 response MUST be returned. In all other aspects (apart, of course, from the lack of 422 response), this command is identical to the LAST command (Section 6.1.3).
現在の記事数はすでにニュースグループの最後の記事であれば、421応答が返されなければなりません。 （離れて、もちろん、422応答の欠如からの）全ての他の態様では、このコマンドが最後のコマンド（6.1.3項）と同じです。
Example of a successful article retrieval using NEXT:
NEXTを使って成功した記事検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] NEXT [S] 223 3000237 <668929@example.org> retrieved
[C] [S] 211 1234 3000234 3002322 misc.test [C] NEXT [S] 223 3000237 <668929@example.org>が取得misc.test GROUP
Example of an attempt to retrieve an article without having selected a group (via the GROUP command) first:
第一（GROUPコマンドによって）グループを選択せずに物品を取得しようとする試みの例：
[Assumes currently selected newsgroup is invalid.] [C] NEXT [S] 412 no newsgroup selected
[現在選択されているニュースグループが無効であると仮定。] [C] NEXT [S] 412ないニュースグループ選択
Example of an attempt to retrieve an article using the NEXT command when the current article number is that of the last article in the group:
現在の記事数がグループ内の最後の記事のそれであるとき、次のコマンドを使用して記事を取得しようとする試みの例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] STAT 3002322 [S] 223 3002322 <411@example.net> retrieved [C] NEXT [S] 421 No next article to retrieve
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] STAT 3002322 [のS] 223 3002322 <411@example.net>取得[C] NEXT [S] 421取得するなし次の記事
Example of an attempt to retrieve an article using the NEXT command when the currently selected newsgroup is empty:
現在選択されているニュースグループが空の場合、NEXTコマンドを使用して記事を取得しようとする試みの例：
[C] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] NEXT [S] 420 No current article selected
[C]グループexample.empty.newsgroup [S] 211 0 0 example.empty.newsgroup [C] NEXT [S] 420は電流記事が選択されていません
The ARTICLE, BODY, HEAD, and STAT commands are very similar. They differ only in the parts of the article that are presented to the client and in the successful response code. The ARTICLE command is described here in full, while the other three commands are described in terms of the differences. As specified in Section 3.6, an article consists of two parts: the article headers and the article body.
ARTICLE、BODY、HEAD、およびSTATコマンドは非常に似ています。彼らは、クライアントに提示し、成功応答コードでされている記事の一部のみが異なります。他の三つのコマンドは違いに関して説明されている間、ARTICLEコマンドは、完全な形でここに記載されています。記事見出しと記事本文：セクション3.6で指定されるように、物品は、2つの部分から構成されています。
When responding to one of these commands, the server MUST present the entire article or appropriate part and MUST NOT attempt to alter or translate it in any way.
これらのいずれかのコマンドに応答するとき、サーバは記事全体または適切な部分を提示しなければなりませんし、どのような方法でそれを変更したり、翻訳することを試みてはいけません。
Indicating capability: READER
示す機能：READER
Syntax ARTICLE message-id ARTICLE number ARTICLE
構文ARTICLEメッセージID物品数ARTICLE
Responses
反応
First form (message-id specified) 220 0|n message-id Article follows (multi-line) 430 No article with that message-id
最初の形式（メッセージIDが指定された）220 0 | n個のメッセージIDの物品は以下の（マルチライン）は、メッセージIDを持つ430なし記事
Second form (article number specified) 220 n message-id Article follows (multi-line) 412 No newsgroup selected 423 No article with that number
第二の形態（資料番号が指定された）220 NメッセージID物品が（マルチライン）以下の412なしニュースグループは、その番号に423なしの記事を選択していません
Third form (current article number used) 220 n message-id Article follows (multi-line) 412 No newsgroup selected 420 Current article number is invalid
412無ニュースグループ420現在の文書番号が無効で選択されていない（現在の文書番号が使用される）第三の形態は220 NメッセージID物品は、（マルチライン）以下
Parameters number Requested article number n Returned article number message-id Article message-id
数要求された記事数n返さ資料番号のメッセージIDの記事のメッセージIDをパラメータ
The ARTICLE command selects an article according to the arguments and presents the entire article (that is, the headers, an empty line, and the body, in that order) to the client. The command has three forms.
ARTICLEコマンドは、引数に従って記事を選択し、クライアントに（その順序ですなわち、ヘッダ、空行、および本体）全体記事を提示します。コマンドは、3つの形式があります。
In the first form, a message-id is specified, and the server presents the article with that message-id. In this case, the server MUST NOT alter the currently selected newsgroup or current article number. This is both to facilitate the presentation of articles that may be referenced within another article being read, and because of the semantic difficulties of determining the proper sequence and membership of an article that may have been cross-posted to more than one newsgroup.
最初の形式で、メッセージIDが指定され、サーバは、そのメッセージIDを有する物品を提供します。この場合、サーバは、現在選択されているニュースグループや現在の記事番号を変更してはいけません。これは読まれている別の記事内で参照することができる記事のプレゼンテーションを容易にするためでもあり、そしてので、複数のニュースグループにクロスポストされている可能性があり、物品の適切な順序とメンバーシップを決定するセマンティック困難の。
In the response, the article number MUST be replaced with zero, unless there is a currently selected newsgroup and the article is present in that group, in which case the server MAY use the article's number in that group. (The server is not required to determine whether the article is in the currently selected newsgroup or, if so, what article number it has; the client MUST always be prepared for zero to be specified.) The server MUST NOT provide an article number unless use of that number in a second ARTICLE command immediately following this one would return the same article. Even if the server chooses to return article numbers in these circumstances, it need not do so consistently; it MAY return zero to any such command (also see the STAT examples, Section 6.2.4.3).
これに応答して、現在選択されているニュースグループが存在しない限り、文書番号は、ゼロに置き換えなければならない物品は、サーバがそのグループ内の記事の数を使用することができる場合には、そのグループで存在します。サーバがない限り、資料番号を提供してはならない;（クライアントは常に指定するゼロのために準備しなければなりません。サーバは記事がもしそうなら、どのような記事数、それは持っている、現在選択されているニュースグループであるかどうかを判断するために必要とされていません）すぐに同じ記事を返します。この1次二ARTICLEコマンドでその番号を使用します。サーバはこのような状況での資料番号を返すことを選択した場合でも、それは一貫してそうする必要はありません。それは（また、セクション6.2.4.3をSTATの例を参照）、そのようなコマンドにはゼロが返されることがあります。
In the second form, an article number is specified. If there is an article with that number in the currently selected newsgroup, the server MUST set the current article number to that number.
第二の形態では、文書番号が指定されています。現在選択されているニュースグループでその番号の記事がある場合は、サーバーはその番号に現在の資料番号を設定しなければなりません。
In the third form, the article indicated by the current article number in the currently selected newsgroup is used.
第三の形態では、現在選択されているニュースグループにおける現在の文書番号で示される物品が使用されます。
Note that a previously valid article number MAY become invalid if the article has been removed. A previously invalid article number MAY become valid if the article has been reinstated, but this article number MUST be no less than the reported low water mark for that group.
記事が削除されている場合、以前に有効な資料番号が無効になる場合があります。記事が復活された場合、以前に無効資料番号が有効になることがありますが、この記事の番号は、そのグループのために報告された低ウォーターマークを満足する必要があります。
The server MUST NOT change the currently selected newsgroup as a result of this command. The server MUST NOT change the current article number except when an article number argument was provided and the article exists; in particular, it MUST NOT change it following an unsuccessful response.
サーバーは、このコマンドの結果として、現在選択されているニュースグループを変更してはなりません。サーバーは記事番号の引数が提供したとの記事がある場合を除き、現在の資料番号を変更してはいけません。特に、それが失敗した応答以下に変更してはなりません。
Since the message-id is unique for each article, it may be used by a client to skip duplicate displays of articles that have been posted more than once, or to more than one newsgroup.
メッセージIDは、各記事に対して一意であるので、複数回、または複数のニュースグループに投稿された記事の重複ディスプレイをスキップするためにクライアントが使用することができます。
The article is returned as a multi-line data block following the 220 response code.
物品は、220応答コード次のマルチラインのデータブロックとして返されます。
If the argument is a message-id and no such article exists, a 430 response MUST be returned. If the argument is a number or is omitted and the currently selected newsgroup is invalid, a 412 response MUST be returned. If the argument is a number and that article does not exist in the currently selected newsgroup, a 423 response MUST be returned. If the argument is omitted and the current article number is invalid, a 420 response MUST be returned.
引数は、メッセージIDであり、そのような物品が存在しない場合、430応答が返されなければなりません。引数が数値であるか省略され、現在選択されているニュースグループが無効である場合、412応答が返されなければなりません。引数が数で、その記事は、現在選択されているニュースグループに存在しない場合は、423応答が返されなければなりません。引数を省略すると、現在の記事番号が無効となる場合は、420応答が返されなければなりません。
Example of a successful retrieval of an article (explicitly not using an article number):
物品（明示的に文書番号を使用していない）の成功した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] ARTICLE [S] 220 3000234 <45223423@example.com> [S] Path: pathost!demo!whitehouse!not-for-mail [S] From: "Demo User" <nobody@example.net> [S] Newsgroups: misc.test [S] Subject: I am just a test article [S] Date: 6 Oct 1998 04:38:40 -0500 [S] Organization: An Example Net, Uncertain, Texas [S] Message-ID: <45223423@example.com> [S] [S] This is just a test article. [S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C]記事[S] 220 3000234 <45223423@example.com> [S]のパス：！！！pathostデモホワイトハウスではない-用メール[ S]から： "デモ・ユーザー" <nobody@example.net> [S]ニュースグループ：misc.test [S]件名：私はちょうどテスト品[S]日付：1998年10月6日午前4時38分40秒-0500 [ S]組織：例ネット、不確かな、テキサス[S]メッセージ-ID：<45223423@example.com> [S] [S]これは単なるテスト品です。 [S]。
Example of a successful retrieval of an article by message-id:
メッセージIDによって物品の成功した検索の例：
[C] ARTICLE <45223423@example.com> [S] 220 0 <45223423@example.com> [S] Path: pathost!demo!whitehouse!not-for-mail [S] From: "Demo User" <nobody@example.net> [S] Newsgroups: misc.test [S] Subject: I am just a test article [S] Date: 6 Oct 1998 04:38:40 -0500 [S] Organization: An Example Net, Uncertain, Texas [S] Message-ID: <45223423@example.com> [S] [S] This is just a test article. [S] .
[C]記事<45223423@example.com> [S] 220 0 <45223423@example.com> [S]のパス：！！！pathostデモホワイトハウスではない-用メール[S]から： "デモ・ユーザー" <誰も@ example.net> [S]ニュースグループ：misc.test [S]件名：私はちょうどテスト品だ[S]日付：1998年10月6日四時38分40秒-0500 [S]組織：例ネット、不確かな、テキサス[S]メッセージ-ID：<45223423@example.com> [S] [S]これは単なるテスト品です。 [S]。
Example of an unsuccessful retrieval of an article by message-id:
メッセージIDによって物品の失敗した検索の例：
[C] ARTICLE <i.am.not.there@example.com> [S] 430 No Such Article Found
[C]記事<i.am.not.there@example.com> [S] 430が見つかりませんこのような条
Example of an unsuccessful retrieval of an article by number:
数による物品の失敗した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 news.groups [C] ARTICLE 300256 [S] 423 No article with that number
[C] GROUP misc.test [S] 211 1234 3000234 3002322 news.groups [C]記事300256 [S] 423という番号を持つ物品
Example of an unsuccessful retrieval of an article by number because no newsgroup was selected first:
数による物品の失敗した検索の例ないニュースグループが最初に選択されなかったため。
[Assumes currently selected newsgroup is invalid.] [C] ARTICLE 300256 [S] 412 No newsgroup selected
[現在選択されているニュースグループが無効であると仮定。] [C]記事300256 [S] 412なしニュースグループ選択
Example of an attempt to retrieve an article when the currently selected newsgroup is empty:
現在選択されているニュースグループが空の場合、物品を取得しようとする試みの例：
[C] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] ARTICLE [S] 420 No current article selected
[C]グループexample.empty.newsgroup [S] 211 0 0 example.empty.newsgroup [C]記事[S] 420が選択されていません現在の記事
This command is mandatory.
このコマンドは必須です。
Syntax HEAD message-id HEAD number HEAD
構文HEADメッセージIDヘッド番号HEAD
Responses
反応
First form (message-id specified) 221 0|n message-id Headers follow (multi-line) 430 No article with that message-id
最初の形式（メッセージIDが指定された）221 0 | Nメッセージ-IDヘッダが（複数行）に従う430そのメッセージIDとは、物品
Second form (article number specified) 221 n message-id Headers follow (multi-line) 412 No newsgroup selected 423 No article with that number
第二の形態（資料番号が指定された）221 Nメッセージ-IDヘッダが（複数行）に従う412なしニュースグループは、その番号に423なしの記事を選択していません
Third form (current article number used) 221 n message-id Headers follow (multi-line) 412 No newsgroup selected 420 Current article number is invalid
第三の形態（現在使用されている文書番号）221 Nメッセージ-IDヘッダが（複数行）に従う412なしニュースグループは420現在の文書番号が無効で選択されていません
Parameters number Requested article number n Returned article number message-id Article message-id
数要求された記事数n返さ資料番号のメッセージIDの記事のメッセージIDをパラメータ
The HEAD command behaves identically to the ARTICLE command except that, if the article exists, the response code is 221 instead of 220 and only the headers are presented (the empty line separating the headers and body MUST NOT be included).
HEADコマンドは、物品が存在する場合、レスポンスコード221の代わりに、220で、ヘッダーのみが（ヘッダとボディを分離する空白行を含んではいけません）に提示されている、ことを除いてARTICLEコマンドと同一に挙動します。
Example of a successful retrieval of the headers of an article (explicitly not using an article number):
（明示的に文書番号を使用していない）物品のヘッダの成功した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HEAD [S] 221 3000234 <45223423@example.com> [S] Path: pathost!demo!whitehouse!not-for-mail [S] From: "Demo User" <nobody@example.net> [S] Newsgroups: misc.test [S] Subject: I am just a test article [S] Date: 6 Oct 1998 04:38:40 -0500 [S] Organization: An Example Net, Uncertain, Texas [S] Message-ID: <45223423@example.com> [S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HEAD [S] 221 3000234 <45223423@example.com> [S]のパス：！！！pathostデモホワイトハウスではない-用メール[ S]から： "デモ・ユーザー" <nobody@example.net> [S]ニュースグループ：misc.test [S]件名：私はちょうどテスト品[S]日付：1998年10月6日午前4時38分40秒-0500 [ S]組織：例ネット、不確かな、テキサス[S]メッセージ-ID：<45223423@example.com> [S]。
Example of a successful retrieval of the headers of an article by message-id:
メッセージIDによる記事のヘッダの成功した検索の例：
[C] HEAD <45223423@example.com> [S] 221 0 <45223423@example.com> [S] Path: pathost!demo!whitehouse!not-for-mail [S] From: "Demo User" <nobody@example.net> [S] Newsgroups: misc.test [S] Subject: I am just a test article [S] Date: 6 Oct 1998 04:38:40 -0500 [S] Organization: An Example Net, Uncertain, Texas [S] Message-ID: <45223423@example.com> [S] .
[C] HEAD <45223423@example.com> [S] 221 0 <45223423@example.com> [S]のパス：！！！pathostデモホワイトハウスではない-用メール[S]から： "デモ・ユーザー" <誰も@ example.net> [S]ニュースグループ：misc.test [S]件名：私はちょうどテスト品だ[S]日付：1998年10月6日四時38分40秒-0500 [S]組織：例ネット、不確かな、テキサス[S]メッセージ-ID：<45223423@example.com> [S]。
Example of an unsuccessful retrieval of the headers of an article by message-id:
メッセージIDによる記事のヘッダの失敗検索の例：
[C] HEAD <i.am.not.there@example.com> [S] 430 No Such Article Found
[C] HEAD <i.am.not.there@example.com> [S] 430はそのような記事が見つかりません
Example of an unsuccessful retrieval of the headers of an article by number:
数による記事のヘッダの失敗検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HEAD 300256 [S] 423 No article with that number
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HEAD 300256 [S] 423という番号を持つ物品
Example of an unsuccessful retrieval of the headers of an article by number because no newsgroup was selected first:
数による記事のヘッダの失敗検索の例ないニュースグループが最初に選択されなかったため。
[Assumes currently selected newsgroup is invalid.] [C] HEAD 300256 [S] 412 No newsgroup selected
[現在選択されているニュースグループが無効であると仮定。] [C] HEAD 300256 [S] 412なしニュースグループ選択
Example of an attempt to retrieve the headers of an article when the currently selected newsgroup is empty:
現在選択されているニュースグループが空の場合、物品のヘッダを取得しようとする試みの例：
[C] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] HEAD [S] 420 No current article selected
[C]グループexample.empty.newsgroup [S] 211 0 0 example.empty.newsgroup [C] HEAD [S] 420が選択されていません現在の記事
Indicating capability: READER
示す機能：READER
Syntax BODY message-id BODY number BODY
構文BODYメッセージID BODY番号BODY
Responses
反応
First form (message-id specified) 222 0|n message-id Body follows (multi-line) 430 No article with that message-id
最初の形式（メッセージIDが指定された）222 0 | n個のメッセージID本体は以下の（マルチライン）は、メッセージIDを持つ430なし記事
Second form (article number specified) 222 n message-id Body follows (multi-line) 412 No newsgroup selected 423 No article with that number
第二の形態（資料番号が指定された）222 NメッセージID本体（マルチライン）以下の412なしニュースグループは、その番号に423なしの記事を選択していません
Third form (current article number used) 222 n message-id Body follows (multi-line) 412 No newsgroup selected 420 Current article number is invalid
第三の形態（現在使用されている文書番号）222 NメッセージID本体（マルチライン）以下の412なしニュースグループは420現在の文書番号が無効で選択されていません
Parameters number Requested article number n Returned article number message-id Article message-id
数要求された記事数n返さ資料番号のメッセージIDの記事のメッセージIDをパラメータ
The BODY command behaves identically to the ARTICLE command except that, if the article exists, the response code is 222 instead of 220 and only the body is presented (the empty line separating the headers and body MUST NOT be included).
BODYコマンドは、物品が存在する場合、レスポンスコード222の代わりに、220であり、唯一の本体（ヘッダとボディを分離する空白行を含んではいけません）に提示され、それ以外ARTICLEコマンドと同一に挙動します。
Example of a successful retrieval of the body of an article (explicitly not using an article number):
（明示的に文書番号を使用していない）物品の身体の成功した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] BODY [S] 222 3000234 <45223423@example.com> [S] This is just a test article. [S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] BODY [S] 222 3000234 <45223423@example.com> [S]これは単なる試験物品です。 [S]。
Example of a successful retrieval of the body of an article by message-id:
メッセージIDにより、物品の身体の成功した検索の例：
[C] BODY <45223423@example.com> [S] 222 0 <45223423@example.com> [S] This is just a test article. [S] .
[C] BODY <45223423@example.com> [S] 222 0 <45223423@example.com> [S]これは単なる試験物品です。 [S]。
Example of an unsuccessful retrieval of the body of an article by message-id:
メッセージIDにより、物品の身体の失敗した検索の例：
[C] BODY <i.am.not.there@example.com> [S] 430 No Such Article Found
[C] BODY <i.am.not.there@example.com> [S] 430はそのような記事が見つかりません
Example of an unsuccessful retrieval of the body of an article by number:
数による物品の身体の失敗した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] BODY 300256 [S] 423 No article with that number
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] BODY 300256 [S] 423という番号を持つ物品
Example of an unsuccessful retrieval of the body of an article by number because no newsgroup was selected first:
数による物品の身体の失敗した検索の例ないニュースグループが最初に選択されなかったため。
[Assumes currently selected newsgroup is invalid.] [C] BODY 300256 [S] 412 No newsgroup selected
[現在選択されているニュースグループが無効であると仮定。] [C] BODY 300256 [S] 412なしニュースグループ選択
Example of an attempt to retrieve the body of an article when the currently selected newsgroup is empty:
現在選択されているニュースグループが空のときに記事の本文を取得しようとする試みの例：
[C] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] BODY [S] 420 No current article selected
[C]グループexample.empty.newsgroup [S] 211 0 0 example.empty.newsgroup [C] BODY [S] 420が選択されていません現在の記事
This command is mandatory.
このコマンドは必須です。
Syntax STAT message-id STAT number STAT
構文STATメッセージID STAT番号STAT
Responses
反応
First form (message-id specified) 223 0|n message-id Article exists 430 No article with that message-id
まずフォーム（メッセージIDが指定された）223 0 | nはメッセージIDの記事が430というメッセージIDとは、物品が存在します
Second form (article number specified) 223 n message-id Article exists 412 No newsgroup selected 423 No article with that number
第二の形態（資料番号が指定された）223 NメッセージID文書412を存在なしニュースグループは、その番号に423なしの記事を選択していません
Third form (current article number used) 223 n message-id Article exists 412 No newsgroup selected 420 Current article number is invalid
いいえニュースグループ420現在の文書番号が無効で選択されていない（現在の文書番号が使用される）第三の形態は223 NメッセージID文書412が存在します
Parameters number Requested article number n Returned article number message-id Article message-id
数要求された記事数n返さ資料番号のメッセージIDの記事のメッセージIDをパラメータ
The STAT command behaves identically to the ARTICLE command except that, if the article exists, it is NOT presented to the client and the response code is 223 instead of 220. Note that the response is NOT multi-line.
STATコマンドは、記事が存在する場合、それはクライアントに提示し、応答コードが223の代わりに、応答が複数行ではありませんことを220注意されないが、ことを除いてARTICLEコマンドとまったく同じ動作をします。
This command allows the client to determine whether an article exists and, in the second and third forms, what its message-id is, without having to process an arbitrary amount of text.
このコマンドは、テキストの任意の量を処理することなく、そのメッセージIDが何であるか第二及び第三の形態において、クライアントは、物品が存在するかどうかを決定することを可能にすると。
Example of STAT on an existing article (explicitly not using an article number):
（明示的に記事番号を使用していない）、既存品のSTATの例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] STAT [S] 223 3000234 <45223423@example.com>
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] STAT [S] 223 3000234 <45223423@example.com>
Example of STAT on an existing article by message-id:
メッセージIDによって既存の物品上のSTATの例：
[C] STAT <45223423@example.com> [S] 223 0 <45223423@example.com>
[C] STAT <45223423@example.com> [S] 223 0 <45223423@example.com>
Example of STAT on an article not on the server by message-id:
メッセージIDにより、サーバー上の記事ではないのSTATの例：
[C] STAT <i.am.not.there@example.com> [S] 430 No Such Article Found
[C] STAT <i.am.not.there@example.com> [S] 430が見つかりませんこのような条
Example of STAT on an article not in the server by number:
数によって、サーバ内の記事ではないのSTATの例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] STAT 300256 [S] 423 No article with that number
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] STAT 300256 [S] 423という番号を持つ物品
Example of STAT on an article by number when no newsgroup was selected first:
何ニュースグループが最初に選択されなかった回数によって物品上のSTATの例：
[Assumes currently selected newsgroup is invalid.] [C] STAT 300256 [S] 412 No newsgroup selected
[現在選択されているニュースグループが無効であると仮定。] [C] STAT 300256 [S] 412なしニュースグループ選択
Example of STAT on an article when the currently selected newsgroup is empty:
現在選択されているニュースグループが空になった記事のSTATの例：
[C] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] STAT [S] 420 No current article selected
[C]グループexample.empty.newsgroup [S] 211 0 0 example.empty.newsgroup [C] STAT [S] 420は電流記事が選択されていません
Example of STAT by message-id on a server that sometimes reports the actual article number:
時には、実際の資料番号を報告し、サーバー上のメッセージIDによるSTATの例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] STAT [S] 223 3000234 <45223423@example.com> [C] STAT <45223423@example.com> [S] 223 0 <45223423@example.com> [C] STAT <45223423@example.com> [S] 223 3000234 <45223423@example.com> [C] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] STAT <45223423@example.com> [S] 223 0 <45223423@example.com> [C] GROUP alt.crossposts [S] 211 9999 111111 222222 alt.crossposts [C] STAT <45223423@example.com> [S] 223 123456 <45223423@example.com> [C] STAT [S] 223 111111 <23894720@example.com>
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] STAT [S] 223 3000234 <45223423@example.com> [C] STAT <45223423@example.com> [S] 223 0 < 45223423@example.com> [C] STAT <45223423@example.com> [S] 223 3000234 <45223423@example.com> [C]グループexample.empty.newsgroup [S] 211 0 0 example.empty.newsgroup [C] STAT <45223423@example.com> [S] 223 0 <45223423@example.com> [C]グループalt.crossposts [S] 211 9999 111111 222222 alt.crossposts [C] STAT <45223423@example.com > [S] 223 123456 <45223423@example.com> [C] STAT [S] 223 111111 <23894720@example.com>
The first STAT command establishes the identity of an article in the group. The second and third show that the server may, but need not, give the article number when the message-id is specified. The fourth STAT command shows that zero must be specified if the article isn't in the currently selected newsgroup. The fifth shows that the number, if provided, must be that relating to the currently selected newsgroup. The last one shows that the current article number is still not changed by the use of STAT with a message-id even if it returns an article number.
最初のSTATコマンドは、グループ内の記事のアイデンティティを確立します。メッセージIDが指定されている場合、サーバが、必須ではないが、文書番号を与えることができる第二及び第三のショー。第STATコマンドは、物品は、現在選択されてニュースグループ内にない場合、ゼロが指定されなければならないことを示しています。第五の数は、提供される場合、現在選択されているニュースグループに関連することでなければならないことを示しています。最後のものは、現在の文書番号がまだそれが文書番号を返した場合でも、メッセージIDを持つSTATの使用によって変更されないことを示しています。
Article posting is done in one of two ways: individual article posting from news-reading clients using POST, and article transfer from other news servers using IHAVE.
POSTを使用してニュース読んでクライアントからの個々の記事の投稿、およびIHAVEを使用して他のニュースサーバーから記事転送：記事の投稿は、次のいずれかの方法で行われます。
Indicating capability: POST
示す機能：POST
This command MUST NOT be pipelined.
このコマンドは、パイプライン化されてはなりません。
Syntax POST
構文POST
Responses
反応
Initial responses 340 Send article to be posted 440 Posting not permitted
初期応答は340 440投稿を掲載することが記事を送信許可されていません
Subsequent responses 240 Article received OK 441 Posting failed
その後の応答は240条に失敗しましたOK 441ポスティングを受け
If posting is allowed, a 340 response MUST be returned to indicate that the article to be posted should be sent. If posting is prohibited for some installation-dependent reason, a 440 response MUST be returned.
投稿が許可されている場合、340応答が掲示されるべき物品が送られるべきであることを示すために返されなければなりません。投稿をいくつかインストールに依存する理由で禁止されている場合は、440応答が返されなければなりません。
If posting is permitted, the article MUST be in the format specified in Section 3.6 and MUST be sent by the client to the server as a multi-line data block (see 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.
転記が許可された場合、物品は、セクション3.6で指定された形式である必要があり、マルチラインデータブロック（セクション3.1.1を参照）のようなサーバにクライアントによって送信されなければなりません。こうしてライン上の単一のドット（「」）テキストの終わりを示しており、元のテキストのドットで始まる行は、伝送中にそのドットを倍増しています。
Following the presentation of the termination sequence by the client, the server MUST return a response indicating success or failure of the article transfer. Note that response codes 340 and 440 are used in direct response to the POST command while 240 and 441 are returned after the article is sent.
クライアントによる終結配列のプレゼンテーションに続いて、サーバは、物品の移転の成功または失敗を示す応答を返さなければなりません。物品が送信された後、240と441が戻されている間、応答コード340及び440は、POSTコマンドに直接応答して使用されることに留意されたいです。
A response of 240 SHOULD indicate that, barring unforeseen server errors, the posted article will be made available on the server and/or transferred to other servers, as appropriate, possibly following further processing. In other words, articles not wanted by the server SHOULD be rejected with a 441 response, rather than being accepted and then discarded silently. However, the client SHOULD NOT assume that the article has been successfully transferred unless it receives an affirmative response from the server and SHOULD NOT assume that it is being made available to other clients without explicitly checking (for example, using the STAT command).
240の応答が予期しないサーバーエラーがなければ、ことを示す必要があり、投稿記事は、おそらく、さらなる処理以下、適宜、サーバ上で利用可能及び/又は他のサーバーに転送されます。つまり、サーバーによってたかっていない記事は、むしろ受け入れられているよりも、441応答で拒否し、その後静かに捨てられるべきです。ただし、クライアントは、サーバからの肯定応答を受信しない限り、記事は正常に転送されたことを仮定するべきではありませんし、それが明示的に（例えば、STATコマンドを使用して）確認することなく、他のクライアントに利用可能行われていることを仮定するべきではありません。
If the session is interrupted before the response is received, it is possible that an affirmative response was sent but has been lost. Therefore, in any subsequent session, the client SHOULD either check whether the article was successfully posted before resending or ensure that the server will allocate the same message-id to the new attempt (see Appendix A.2). The latter approach is preferred since the article might not have been made available for reading yet (for example, it may have to go through a moderation process).
応答が受信される前に、セッションが中断された場合、肯定応答が送信されましたが、失われている可能性があります。そのため、後続のセッションで、クライアントはどちらかの記事が正常に再送信するか、サーバーが新しい試みに同じメッセージIDを割り当てることを保証する前にポストされたかどうかを確認する必要があります（付録A.2を参照してください）。物品は、（例えば、それが緩和プロセスを通過する必要がある可能性があり）、まだ読み出しのために利用可能にされていない可能性があるので、後者の方法が好ましいです。
Example of a successful posting:
成功した投稿の例：
[C] POST [S] 340 Input article; end with <CR-LF>.<CR-LF> [C] From: "Demo User" <nobody@example.net> [C] Newsgroups: misc.test [C] Subject: I am just a test article [C] Organization: An Example Net [C] [C] This is just a test article. [C] . [S] 240 Article received OK
[C] POST [S] 340入力物品。 <CR-LF>で終わる<CR-LF> [C]から： "デモ・ユーザー" <nobody@example.net> [C]ニュースグループ：misc.test [C]件名：私はちょうどテスト品だ[C 】組織：例ネット[C] [C]これは単に試験物品です。 [C]。 [S] 240条には、[OK]を受信しました
Example of an unsuccessful posting:
失敗した投稿の例：
[C] POST [S] 340 Input article; end with <CR-LF>.<CR-LF> [C] From: "Demo User" <nobody@example.net> [C] Newsgroups: misc.test [C] Subject: I am just a test article [C] Organization: An Example Net [C] [C] This is just a test article. [C] . [S] 441 Posting failed
[C] POST [S] 340入力物品。 <CR-LF>で終わる<CR-LF> [C]から： "デモ・ユーザー" <nobody@example.net> [C]ニュースグループ：misc.test [C]件名：私はちょうどテスト品だ[C 】組織：例ネット[C] [C]これは単に試験物品です。 [C]。 [S] 441投稿に失敗しました
Example of an attempt to post when posting is not allowed:
投稿が許可されていない時に投稿しようとする試みの例：
[Initial connection set-up completed.] [S] 201 NNTP Service Ready, posting prohibited [C] POST [S] 440 Posting not permitted
[初期接続セットアップが完了しました。] [S] 201 NNTPサービスの準備、禁止[C] POST [S] 440ポスティング許可されていないの投稿
Indicating capability: IHAVE
示す機能：IHAVE
This command MUST NOT be pipelined.
このコマンドは、パイプライン化されてはなりません。
Syntax IHAVE message-id
構文IHAVEメッセージ-ID
Responses
反応
Initial responses 335 Send article to be transferred 435 Article not wanted 436 Transfer not possible; try again later
; 335できない436の転送を望んでいない435条を転送する記事を送信する初期応答あとでもう一度試してみてください
Subsequent responses 235 Article transferred OK 436 Transfer failed; try again later 437 Transfer rejected; do not retry
その後の応答は235条に失敗しましたOK 436転送を転送します。後でもう一度拒否された437の転送を試してみてください。再試行しないでください
Parameters message-id Article message-id
パラメータメッセージID記事のメッセージID
The IHAVE 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 335 response MUST be returned, instructing the client to send the entire article. If the server does not want the article (if, for example, the server already has a copy of it), a 435 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 is in the process of sending the same article to the server), a 436 response MUST be returned.
IHAVEコマンドは、クライアントが指定したメッセージIDとの記事があり、サーバーに通知します。サーバーがその記事のコピーを希望する場合は、335応答は、全体の記事を送信するためにクライアントに指示、返さなければなりません。サーバは（例えば、サーバはすでにそれのコピーを持っている場合）の記事を望んでいない場合は、435応答は、物品が欲しかっされていないことを示す、返さなければなりません。記事は、（例えば、別のクライアントがサーバに同じ記事を送信するプロセスである、あれば）すぐに望んでいたのではなく、可能な場合、クライアントは、後で再試行する必要がある場合は最後に、436応答が返されなければなりません。
If transmission of the article is requested, the client MUST send the entire article, including headers and body, to the server as a multi-line data block (see 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 a 235 response, indicating that the article was successfully transferred; a 436 response, indicating that the transfer failed but should be tried again later; or a 437 response, indicating that the article was rejected.
記事の送信を要求された場合、クライアントは、複数行のデータブロック（セクション3.1.1を参照）のようなサーバに、ヘッダと本体を含む全体の記事を送信しなければなりません。このように、ライン上の単一のドット（「」）テキストの終わりを示しており、元のテキストのドットで始まる行は、伝送中にそのドットを倍増しています。サーバは、物品が正常に転送されたことを示す、235応答を返さなければなりません。転送が失敗したが、後で再試行されるべきであることを示す436応答。または437応答は、記事が拒否されたことを示しています。
This function differs from the POST command in that it is intended for use in transferring already-posted articles between hosts. It 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, disc 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.
この機能は、それがホスト間で既に掲載記事を転送する際に使用することを意図されている点でPOSTコマンドとは異なります。このコマンドを使用すると、記事はすでに別のサイトに掲載されており、単に別のホストから転送されていることを示しているので、クライアントは、個人のニュース読み取りプログラムであるときには使うべきではありません。しかし、それにもかかわらず、サーバーは、物品の更なる検討の後、それはそうすることが不適切と判断、場合記事を投稿したり、転送しないことを選択できます。物品のようなその後の拒絶理由は、不適切なニュースグループまたは配布、ディスクスペースの制限、物品の長さ、文字化けヘッダなどの問題を含んでいてもよいです。これらは、典型的には、サーバホストのニュースソフトウェアによって必ずしも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) SHOULD be treated the same as a 436 response.
クライアントは、サーバからの肯定応答を受信しない限り、記事は正常に転送されたことを仮定するべきではありません。 （例えばドロップネットワーク接続またはネットワークタイムアウトなど）応答の欠如は、436応答と同じように扱われるべきです。
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 235 response) but later silently discard it.
いくつかのニュースサーバーソフトウェアは、すぐに記事が掲載または転送に適しているかどうかを決定することができない場合がありますので、NNTPサーバは（235応答で）、物品の成功転送を認めたが、後に静かにそれを捨てるかもしれ。
Example of successfully sending an article to another site:
成功した別のサイトに記事を送信する例：
[C] IHAVE <i.am.an.article.you.will.want@example.com> [S] 335 Send it; end with <CR-LF>.<CR-LF> [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] 235 Article transferred OK
[C] IHAVE <i.am.an.article.you.will.want@example.com> [S] 335は、それを送ります。 <CR-LF>で終わる<CR-LF> [C]のパス：。！！！pathostデモどこかにない-用メール[C]から： "デモ・ユーザー" <nobody@example.com> [C]ニュースグループ： misc.test [C]件名：1998年10月6日4時38分40秒-0500 [C]組織：例：COM、サンノゼ、CA [C]メッセージ-ID：<私はちょうどテストの記事[C]日午前i.am.an.article.you.will.want@example.com> [C] [C]これは単なるテスト品です。 [C]。 [S] 235条には、[OK]を転送しました
Example of sending an article to another site that rejects it. Note that the message-id in the IHAVE command is not the same as the one in the article headers; while this is bad practice and SHOULD NOT be done, it is not forbidden.
それを拒否した別のサイトに記事を送信する例。 IHAVEコマンド内のメッセージIDが物品ヘッダのものと同じではないことに留意されたいです。これは悪い習慣で、行われるべきではありませんが、それは禁止されていません。
[C] IHAVE <i.am.an.article.you.will.want@example.com> [S] 335 Send it; end with <CR-LF>.<CR-LF> [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] This is just a test article. [C] . [S] 437 Article rejected; don't send again
[C] IHAVE <i.am.an.article.you.will.want@example.com> [S] 335は、それを送ります。 <CR-LF>で終わる<CR-LF> [C]のパス：。！！！pathostデモどこかにない-用メール[C]から： "デモ・ユーザー" <nobody@example.com> [C]ニュースグループ： misc.test [C]件名：1998年10月6日4時38分40秒-0500 [C]組織：例：COM、サンノゼ、CA [C]メッセージ-ID：<私はちょうどテストの記事[C]日午前i.am.an.article.you.have@example.com> [C] [C]これは単なるテスト品です。 [C]。 [S] 437条は拒否しました。再送信されません
Example of sending an article to another site where the transfer fails:
転送が失敗した別のサイトに記事を送信する例：
[C] IHAVE <i.am.an.article.you.will.want@example.com> [S] 335 Send it; end with <CR-LF>.<CR-LF> [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] 436 Transfer failed
[C] IHAVE <i.am.an.article.you.will.want@example.com> [S] 335は、それを送ります。 <CR-LF>で終わる<CR-LF> [C]のパス：。！！！pathostデモどこかにない-用メール[C]から： "デモ・ユーザー" <nobody@example.com> [C]ニュースグループ： misc.test [C]件名：1998年10月6日4時38分40秒-0500 [C]組織：例：COM、サンノゼ、CA [C]メッセージ-ID：<私はちょうどテストの記事[C]日午前i.am.an.article.you.will.want@example.com> [C] [C]これは単なるテスト品です。 [C]。 [S] 436の転送に失敗しました
Example of sending an article to a site that already has it:
すでにそれを持っているサイトに記事を送信する例：
[C] IHAVE <i.am.an.article.you.have@example.com> [S] 435 Duplicate
[C] IHAVE <i.am.an.article.you.have@example.com> [S] 435重複
Example of sending an article to a site that requests that the article be tried again later:
記事を後で再び試行するように要求し、サイトに記事を送信する例：
[C] IHAVE <i.am.an.article.you.defer@example.com> [S] 436 Retry later
[C] IHAVE <i.am.an.article.you.defer@example.com> [S] 436の再試行後
This section lists other commands that may be used at any time between the beginning of a session and its termination. Using these commands does not alter any state information, but the response generated from their use may provide useful information to clients.
このセクションでは、セッションの開始とその終了の間にいつでも使用することができる他のコマンドを示します。これらのコマンドを使用すると、任意の状態情報を変更しませんが、その使用から生成された応答は、クライアントに有益な情報を提供することができます。
Indicating capability: READER
示す機能：READER
Syntax DATE
構文DATE
Responses 111 yyyymmddhhmmss Server date and time
応答111 YYYYMMDDHHMMSSサーバーの日付と時刻
Parameters yyyymmddhhmmss Current UTC date and time on server
パラメータは、サーバ上の現在のUTCの日付と時刻をYYYYMMDDHHMMSS
This command exists to help clients find out the current Coordinated Universal Time [TF.686-1] from the server's perspective. This command SHOULD NOT be used as a substitute for NTP [RFC1305] but to provide information that might be useful when using the NEWNEWS command (see Section 7.4).
このコマンドは、クライアントがサーバーの観点から現在の協定世界時[TF.686-1]を見つける手助けするために存在します。このコマンドは、NTP [RFC1305]の代替として使用されるべきではなく、NEWNEWSコマンドを（7.4節を参照）を使用する際に役に立つかもしれない情報を提供します。
The DATE command MUST return a timestamp from the same clock as is used for determining article arrival and group creation times (see Section 6). This clock SHOULD be monotonic, and adjustments SHOULD be made by running it fast or slow compared to "real" time rather than by making sudden jumps. A system providing NNTP service SHOULD keep the system clock as accurate as possible, either with NTP or by some other method.
DATEコマンド（セクション6を参照）、物品到着とグループ作成時刻を決定するために使用されるのと同じクロックからタイムスタンプを返さなければなりません。このクロックは単調であるべきであり、調整は「本当の」時間にではなく、突然のジャンプを行うことによって比較した、それが速いか遅い実行することによってなされるべきです。 NNTPサービスを提供するシステムは、NTPまたは他のいくつかの方法のいずれかによって、可能な限り正確なように、システムクロックを維持する必要があります。
The server MUST return a 111 response specifying the date and time on the server in the form yyyymmddhhmmss. This date and time is in Coordinated Universal Time.
サーバーはyyyymmddhhmmssの形式でサーバー上の日付と時刻を指定して111応答を返さなければなりません。この日時は協定世界時です。
[C] DATE
[S] 111 19990623135624
This command is mandatory.
このコマンドは必須です。
Syntax HELP
構文HELP
Responses 100 Help text follows (multi-line)
回答100ヘルプテキストは、次の（複数行）
This command provides a short summary of the commands that are understood by this implementation of the server. The help text will be presented as a multi-line data block following the 100 response code.
このコマンドは、サーバーのこの実装によって理解されているコマンドの短い要約を提供します。ヘルプテキストは、100応答コード次のマルチラインのデータブロックとして提示されます。
This text is not guaranteed to be in any particular format (but must be UTF-8) and MUST NOT be used by clients as a replacement for the CAPABILITIES command described in Section 5.2.
このテキストは、特定のフォーマットであることが保証されていません（ただし、UTF-8でなければならない）と5.2節で説明capabilitiesコマンドの代替としてクライアントが使用してはいけません。
[C] HELP
[S] 100 Help text follows
[S] This is some help text. There is no specific
[S] formatting requirement for this test, though
[S] it is customary for it to list the valid commands
[S] and give a brief definition of what they do.
[S] .
Indicating capability: READER
示す機能：READER
Syntax NEWGROUPS date time [GMT]
構文NEWGROUPS日時[GMT]
Responses 231 List of new newsgroups follows (multi-line)
新しいニュースグループの応答231リストは、次の（複数行）
Parameters date Date in yymmdd or yyyymmdd format time Time in hhmmss format
HHMMSS形式でYYMMDDまたはYYYYMMDD形式時間の時間のパラメータ日付日
This command returns a list of newsgroups created on the server since the specified date and time. The results are in the same format as the LIST ACTIVE command (see Section 7.6.3). However, they MAY include groups not available on the server (and so not returned by LIST ACTIVE) and MAY omit groups for which the creation date is not available.
このコマンドは、指定した日時以降のサーバー上で作成ニュースグループのリストを返します。結果は、LIST ACTIVEコマンド（セクション7.6.3を参照）と同じ形式です。しかし、彼らは、サーバー上で利用できません（そのためLIST ACTIVEによって返さない）基を含んでもよいし、作成日が利用できないためにグループを省略することができます。
The date is specified as 6 or 8 digits in the format [xx]yymmdd, where xx is the first two digits of the year (19-99), yy is the last two digits of the year (00-99), mm is the month (01-12), and dd is the day of the month (01-31). Clients SHOULD specify all four digits of the year. If the first two digits of the year are not specified (this is supported only for backward compatibility), the year is to be taken from the current century if yy is smaller than or equal to the current year, and the previous century otherwise.
日付形式で6または8桁として指定xxは年（19から99）の最初の2桁であり、YYは年の最後の2桁である[XX] YYMMDD、（00〜99）、MMはです月（01-12）、およびddは月（1月31日）の日です。クライアントは、年の4桁すべてを指定する必要があります。年の最初の2桁が（これは下位互換性のためにのみサポートされている）が指定されていない場合、その年はyyは現在の年以下である場合、現在の世紀から採取される、前世紀さもなければ。
The time is specified as 6 digits in the format hhmmss, where hh is the hours in the 24-hour clock (00-23), mm is the minutes (00-59), and ss is the seconds (00-60, to allow for leap seconds). The token "GMT" specifies that the date and time are given in Coordinated Universal Time [TF.686-1]; if it is omitted, then the date and time are specified in the server's local timezone. Note that there is no way of using the protocol specified in this document to establish the server's local timezone.
時間は、HHは24時間制（00-23）で時間である形式HHMMSS、6桁として指定され、mmは分（00-59）であり、そしてssは秒（00から60になります）うるう秒を可能にします。トークン「GMTは、」日付と時刻は協定世界時[TF.686-1]に記載されていることを指定します。それが省略された場合は、日付と時刻は、サーバーのローカルタイムゾーンに指定されています。サーバのローカルタイムゾーンを確立するために、この文書で指定されたプロトコルを使用する方法がないことに注意してください。
Note that an empty list is a possible valid response and indicates that there are no new newsgroups since that date-time.
空のリストが可能有効な応答であり、その日時以降の新しいニュースグループが存在しないことを示していることに注意してください。
Clients SHOULD make all queries using Coordinated Universal Time (i.e., by including the "GMT" argument) when possible.
クライアントは、協定世界時（すなわち、「GMT」引数を含めることによって）可能な場合を使用して、すべてのクエリを行う必要があります。
Example where there are new groups:
新しいグループがある例：
[C] NEWGROUPS 19990624 000000 GMT [S] 231 list of new newsgroups follows [S] alt.rfc-writers.recovery 4 1 y [S] tx.natives.recovery 89 56 y [S] .
[C]は19990624 000000 GMT新しいニュースグループの[S] 231リストは、[S]を以下NEWGROUPS alt.rfc-writers.recovery 4 1 Y [S] tx.natives.recovery 89 56 Y [S]。
Example where there are no new groups:
新たなグループが存在しない例：
[C] NEWGROUPS 19990624 000000 GMT [S] 231 list of new newsgroups follows [S] .
[C]は19990624 000000 GMT新しいニュースグループの[S] 231リストは、[S]を以下NEWGROUPS。
Indicating capability: NEWNEWS
示す機能：NEWNEWS
Syntax NEWNEWS wildmat date time [GMT]
構文NEWNEWS WILDMAT日付時刻[GMT]
Responses 230 List of new articles follows (multi-line)
新しい記事の応答230リストは、次の（複数行）
Parameters wildmat Newsgroups of interest date Date in yymmdd or yyyymmdd format time Time in hhmmss format
HHMMSS形式でYYMMDDまたはYYYYMMDD形式時間の時間に興味日付のニュースグループWILDMATパラメータ
This command returns a list of message-ids of articles posted or received on the server, in the newsgroups whose names match the wildmat, since the specified date and time. One message-id is sent on each line; the order of the response has no specific significance and may vary from response to response in the same session. A message-id MAY appear more than once; if it does, it has the same meaning as if it appeared only once.
このコマンドは、指定した日時以降、名前WILDMATと一致ニュースグループでは、サーバー上に掲載または受信記事のメッセージIDのリストを返します。一つのメッセージIDは、各ライン上に送信されます。応答の順序は、特別な意味を持たず、同じセッションにおける応答に応じ異なっていてもよいです。メッセージIDが複数回表示されることがあります。それがない場合、それは一度だけ登場しているかのように、同じ意味を持ちます。
Date and time are in the same format as the NEWGROUPS command (see Section 7.3).
日付と時刻は（7.3節を参照）NEWGROUPSコマンドと同じ形式です。
Note that an empty list is a possible valid response and indicates that there is currently no new news in the relevant groups.
空のリストが可能有効な応答で、関連するグループには新しいニュースが現在存在しないことを示していることに注意してください。
Clients SHOULD make all queries in Coordinated Universal Time (i.e., by using the "GMT" argument) when possible.
可能な場合、クライアントは協定世界時（すなわち、「GMT」引数を使用して）ですべてのクエリを行う必要があります。
Example where there are new articles:
新しい記事があります。例：
[C] NEWNEWS news.*,sci.* 19990624 000000 GMT [S] 230 list of new articles by message-id follows [S] <i.am.a.new.article@example.com> [S] <i.am.another.new.article@example.com> [S] .
[C] NEWNEWSニュース。*、SCI。* 19990624 000000 GMT [S]メッセージID、以下の[S] <i.am.a.new.article@example.com> [S] <Iによる新記事の230リスト.am.another.new.article @ example.com> [S]。
Example where there are no new articles:
新しい記事は存在しない例：
[C] NEWNEWS alt.* 19990624 000000 GMT [S] 230 list of new articles by message-id follows [S] .
[C] NEWNEWSのALTは。* 19990624 000000 GMTは、[S]はメッセージIDによって新しい記事の230のリストは、[S]は以下。
As described in Section 6, each article has an arrival timestamp. Each newsgroup also has a creation timestamp. These timestamps are used by the NEWNEWS and NEWGROUP commands to construct their responses.
第6節で説明したように、各記事が到着タイムスタンプを有しています。各ニュースグループも作成タイムスタンプを持っています。これらのタイムスタンプはNEWNEWSとNEWGROUPその応答を構築するためのコマンドで使用されています。
Clients can ensure that they do not have gaps in lists of articles or groups by using the DATE command in the following manner:
クライアントは、次のようにDATEコマンドを使って、記事やグループのリストのギャップを持っていないことを確認することができます。
First session: Issue DATE command and record result. Issue NEWNEWS command using a previously chosen timestamp.
最初のセッション：発行日コマンドとレコードの結果。以前に選択したタイムスタンプを利用して発行NEWNEWSコマンド。
Subsequent sessions: Issue DATE command and hold result in temporary storage. Issue NEWNEWS command using timestamp saved from previous session. Overwrite saved timestamp with that currently in temporary storage.
その後のセッション：発行日コマンドや一時記憶につながる開催。前のセッションで保存されたタイムスタンプを利用して発行NEWNEWSコマンド。上書きは現在、一時的に記憶しているとタイムスタンプを保存します。
In order to allow for minor errors, clients MAY want to adjust the timestamp back by two or three minutes before using it in NEWNEWS.
軽微なエラーを可能にするために、クライアントはNEWNEWSでそれを使用する前に、二、三分で戻ってタイムスタンプを調整することもできます。
First session:
最初のセッション：
[C] DATE [S] 111 20010203112233 [C] NEWNEWS local.chat 20001231 235959 GMT [S] 230 list follows [S] <article.1@local.service> [S] <article.2@local.service> [S] <article.3@local.service> [S] .
[C] DATE [S] 111 20010203112233 [C] NEWNEWSは20001231 235959をlocal.chat GMT [S] 230のリストは、以下の[S] <article.1@local.service> [S] <article.2@local.service> [ S] <article.3@local.service> [S]。
Second session (the client has subtracted 3 minutes from the timestamp returned previously):
セカンドセッション（クライアントが以前に返されたタイムスタンプから3分を差し引きました）：
[C] DATE [S] 111 20010204003344 [C] NEWNEWS local.chat 20010203 111933 GMT [S] 230 list follows [S] <article.3@local.service> [S] <article.4@local.service> [S] <article.5@local.service> [S] .
[C] DATE [S] 111 20010204003344 [C] NEWNEWSは20010203 111933をlocal.chat GMT [S] 230のリストは、以下の[S] <article.3@local.service> [S] <article.4@local.service> [ S] <article.5@local.service> [S]。
Note how <article.3@local.service> arrived in the 3 minute gap and so is listed in both responses.
<article.3@local.service> 3分のギャップに到着し、その応答の両方にリストされているかに注意してください。
The LIST family of commands all return information that is multi-line and that can, in general, be expected not to change during the session. Often the information is related to newsgroups, in which case the response has one line per newsgroup and a wildmat MAY be provided to restrict the groups for which information is returned.
コマンドの一覧ファミリのマルチラインであり、それは、一般的には、セッション中に変更しないと予想することができます。すべての戻り情報多くの場合、情報は、ニュースグループに関連し、その場合、応答は、ニュースグループごとにラインを有し、WILDMATは、情報が返されるのグループを制限するために提供されてもよいです。
The set of available keywords (including those provided by extensions) is given in the capability list with capability label LIST.
（拡張子が提供するものを含む）使用可能なキーワードのセットが機能ラベルリストと能力のリストに記載されています。
Indicating capability: LIST
示す機能：LIST
Syntax LIST [keyword [wildmat|argument]]
構文LIST [キーワード[WILDMAT |引数]]
Responses 215 Information follows (multi-line)
215の情報は、以下の回答（複数行）
Parameters keyword Information requested [1] argument Specific to keyword wildmat Groups of interest
固有のパラメータキーワードの情報要求された[1]引数は、目的のグループWILDMATキーワードに
[1] If no keyword is provided, it defaults to ACTIVE.
ACTIVEへ[1]キーワードが提供されていない場合、それがデフォルトになります。
The LIST command allows the server to provide blocks of information to the client. This information may be global or may be related to newsgroups; in the latter case, the information may be returned either for all groups or only for those matching a wildmat. Each block of information is represented by a different keyword. The command returns the specific information identified by the keyword.
LISTコマンドは、サーバーがクライアントに情報のブロックを提供することができます。この情報はグローバルであってもよいし、ニュースグループに関連する可能性があります。後者の場合、情報は、すべてのグループに対してのみWILDMATに一致するためのいずれかで戻すことができます。情報の各ブロックは、異なるキーワードによって表されます。コマンドには、キーワードによって識別される特定の情報を返します。
If the information is available, it is returned as a multi-line data block following the 215 response code. The format of the information depends on the keyword. The information MAY be affected by the additional argument, but the format MUST NOT be.
情報が利用可能である場合、それは215応答コード次のマルチラインのデータブロックとして返されます。情報のフォーマットは、キーワードによって異なります。情報には、追加の引数によって影響を受ける可能性がありますが、フォーマットはしているはずがありません。
If the information is based on newsgroups and the optional wildmat argument is specified, the response is limited to only the groups (if any) whose names match the wildmat and for which the information is available.
情報は、ニュースグループに基づいており、任意WILDMAT引数が指定されている場合、応答は、名前WILDMATと一致し、そのための情報が利用可能である唯一のグループ（もしあれば）に限定されます。
Note that an empty list is a possible valid response; for a newsgroup-based keyword, it indicates that there are no groups meeting the above criteria.
空のリストが可能有効な応答であることに注意してください。ニュースグループベースのキーワードに対して、それが上記の基準を満たすグループがないことを示しています。
If the keyword is not recognised, or if an argument is specified and the keyword does not expect one, a 501 response code MUST BE returned. If the keyword is recognised but the server does not maintain the information, a 503 response code MUST BE returned.
キーワードが認識されない場合、引数が指定された場合、またはキーワードは501レスポンスコードが返される必要があり、1期待していません。キーワードが認識されているが、サーバーが情報を保持していない場合は、503レスポンスコードが返されなければなりません。
The LIST command MUST NOT change the visible state of the server in any way; that is, the behaviour of subsequent commands MUST NOT be affected by whether the LIST command was issued. For example, it MUST NOT make groups available that otherwise would not have been.
LISTコマンドは、どのような方法で、サーバの可視状態を変更してはいけません。つまり、後続のコマンドの動作は、LISTコマンドが発行されたかどうかによって影響を受けてはなりません。例えば、それはそうしていないだろうとのグループが利用できるようにしてはなりません。
Example of LIST with the ACTIVE keyword:
ACTIVEキーワードとリストの例：
[C] LIST ACTIVE [S] 215 list of newsgroups follows [S] misc.test 3002322 3000234 y [S] comp.risks 442001 441099 m [S] alt.rfc-writers.recovery 4 1 y [S] tx.natives.recovery 89 56 y [S] tx.natives.recovery.d 11 9 n [S] .
ニュースグループの[C] LIST ACTIVE [S] 215のリストは、[S] misc.test 3002322 3000234 Y [S]は442001 441099メートル[S] alt.rfc-writers.recovery 4 1つのY [S] tx.nativesをcomp.risks以下.recovery 89 56 Y [S]は11 9 N [S]をtx.natives.recovery.d。
Example of LIST with no keyword:
キーワードなしでリストの例：
[C] LIST [S] 215 list of newsgroups follows [S] misc.test 3002322 3000234 y [S] comp.risks 442001 441099 m [S] alt.rfc-writers.recovery 4 1 y [S] tx.natives.recovery 89 56 y [S] tx.natives.recovery.d 11 9 n [S] .
[C] LIST [S]ニュースグループのリスト215は、以下の[S] misc.test 3002322 3000234 Y [S]は442001 441099メートル[S] alt.rfc-writers.recovery 4 1つのY [S] tx.nativesをcomp.risks。回復89 56 Y [S]は[S] 11 9 Nをtx.natives.recovery.d。
The output is identical to that of the previous example.
出力は、前の例と同じです。
Example of LIST on a newsgroup-based keyword with and without wildmat:
ととWILDMATなしのニュースグループベースのキーワードのリストの例：
[C] LIST ACTIVE.TIMES [S] 215 information follows [S] misc.test 930445408 <creatme@isc.org> [S] alt.rfc-writers.recovery 930562309 <m@example.com> [S] tx.natives.recovery 930678923 <sob@academ.com> [S] . [C] LIST ACTIVE.TIMES tx.* [S] 215 information follows [S] tx.natives.recovery 930678923 <sob@academ.com> [S] .
[C] LISTは、[S] 215の情報は、以下の[S] misc.test 930445408 <creatme@isc.org> [S] alt.rfc-writers.recovery 930562309 <m@example.com> [S] TXをACTIVE.TIMES。 natives.recovery 930678923 <sob@academ.com> [S]。 [C] LISTはTX ACTIVE.TIMES。* [S] 215の情報は、以下の[S] tx.natives.recovery 930678923 <sob@academ.com> [S]。
Example of LIST returning an error where the keyword is recognized but the software does not maintain this information:
LISTの例は、キーワードが認識されているエラーを返すが、ソフトウェアは、この情報を維持しません。
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA [S] . [C] LIST XTRA.DATA [S] 503 Data item not stored
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA [S]。 [C] LIST XTRA.DATA [S] 503データ項目が記憶されていません
Example of LIST where the keyword is not recognised:
キーワードは認識されないリストの例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA [S] . [C] LIST DISTRIB.PATS [S] 501 Syntax Error
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA [S]。 [C]のリストDISTRIB.PATS [S] 501構文エラー
This specification defines the following LIST keywords:
この仕様は、以下のリストのキーワードを定義しています。
+--------------+---------------+------------------------------------+
| Keyword | Definition | Status |
+--------------+---------------+------------------------------------+
| ACTIVE | Section 7.6.3 | Mandatory if the READER capability |
| | | is advertised |
| | | |
| ACTIVE.TIMES | Section 7.6.4 | Optional |
| | | |
| DISTRIB.PATS | Section 7.6.5 | Optional |
| | | |
| HEADERS | Section 8.6 | Mandatory if the HDR capability is |
| | | advertised |
| | | |
| NEWSGROUPS | Section 7.6.6 | Mandatory if the READER capability |
| | | is advertised |
| | | |
| OVERVIEW.FMT | Section 8.4 | Mandatory if the OVER capability |
| | | is advertised |
+--------------+---------------+------------------------------------+
Where one of these LIST keywords is supported by a server, it MUST have the meaning given in the relevant sub-section.
これらLISTキーワードの一つがサーバによってサポートされている場合は、それは、関連するサブセクションで与えられた意味を持っていなければなりません。
This keyword MUST be supported by servers advertising the READER capability.
このキーワードは、READER機能を公示サーバでサポートしなければなりません。
LIST ACTIVE returns a list of valid newsgroups and associated information. If no wildmat is specified, the server MUST include every group that the client is permitted to select with the GROUP command (Section 6.1.1). Each line of this list consists of four fields separated from each other by one or more spaces:
ACTIVE LISTは、有効なニュースグループとそれに関連する情報のリストを返します。何WILDMATが指定されていない場合、サーバーは、クライアントがGROUPコマンド（6.1.1項）で選択することが許可されているすべてのグループを含まなければなりません。このリストの各行は、1つ以上のスペースによって互いに区切られた4つのフィールドで構成されています。
o The name of the newsgroup. o The reported high water mark for the group. o The reported low water mark for the group. o The current status of the group on this server.
ニュースグループの名前O。グループのために報告されたハイウォーターマークO。グループのために報告された低ウォーターマークO。このサーバー上のグループの現在の状態O。
The reported high and low water marks are as described in the GROUP command (see Section 6.1.1), but note that they are in the opposite order to the 211 response to that command.
報告された高および低ウォーターマークがGROUPコマンドに記載されているように（セクション6.1.1を参照）であるが、それらは、そのコマンドに211応答とは逆の順序であることに注意します。
The status field is typically one of the following:
statusフィールドは、通常、次のいずれかです。
"y" Posting is permitted.
「y」の投稿を許可されています。
"n" Posting is not permitted.
「n」は投稿が許可されていません。
"m" Postings will be forwarded to the newsgroup moderator.
「m」の投稿には、ニュースグループのモデレータに転送されます。
The server SHOULD use these values when these meanings are required and MUST NOT use them with any other meaning. Other values for the status may exist; the definition of these other values and the circumstances under which they are returned may be specified in an extension or may be private to the server. A client SHOULD treat an unrecognized status as giving no information.
サーバーは、これらの意味が必要な場合、これらの値を使用すべきであるし、他の意味でそれらを使用してはなりません。ステータスの他の値が存在してもよいです。これらの他の値と、彼らが返されれる状況の定義は、拡張子で指定することができるか、サーバーにプライベートかもしれません。クライアントは何の情報も与えないよう、認識されない状況を扱うべきです。
The status of a newsgroup only indicates how posts to that newsgroup are normally processed and is not necessarily customised to the specific client. For example, if the current client is forbidden from posting, then this will apply equally to groups with status "y". Conversely, a client with special privileges (not defined by this specification) might be able to post to a group with status "n".
ニュースグループのステータスは、そのニュースグループへの投稿が正常に処理されており、必ずしも特定のクライアントに合わせてカスタマイズされていないかを示します。現在のクライアントは、投稿を禁止されている場合、これは、ステータス「Y」を持つグループにも同様に適用されます。逆に、特別な権限（この仕様で定義されていない）を持つクライアントは、ステータスが「N」でグループに投稿することができるかもしれません。
For example:
例えば：
[C] LIST ACTIVE [S] 215 list of newsgroups follows [S] misc.test 3002322 3000234 y [S] comp.risks 442001 441099 m [S] alt.rfc-writers.recovery 4 1 y [S] tx.natives.recovery 89 56 y [S] tx.natives.recovery.d 11 9 n [S] .
ニュースグループの[C] LIST ACTIVE [S] 215のリストは、[S] misc.test 3002322 3000234 Y [S]は442001 441099メートル[S] alt.rfc-writers.recovery 4 1つのY [S] tx.nativesをcomp.risks以下.recovery 89 56 Y [S]は11 9 N [S]をtx.natives.recovery.d。
or, on an implementation that includes leading zeroes:
または、先行ゼロが含まれ、実装上：
[C] LIST ACTIVE [S] 215 list of newsgroups follows [S] misc.test 0003002322 0003000234 y [S] comp.risks 0000442001 0000441099 m [S] alt.rfc-writers.recovery 0000000004 0000000001 y [S] tx.natives.recovery 0000000089 0000000056 y [S] tx.natives.recovery.d 0000000011 0000000009 n [S] .
[C] LIST ACTIVE [S]ニュースグループのリスト215は、[S] misc.test 0003002322 0003000234 Y [S] 0000442001 0000441099メートルをcomp.risks [S] alt.rfc-writers.recovery 0000000004 0000000001 Y [S] tx.nativesに従います.recovery 0000000089 0000000056 Y [S]は0000000011 0000000009 N [S]をtx.natives.recovery.d。
The information is newsgroup based, and a wildmat MAY be specified, in which case the response is limited to only the groups (if any) whose names match the wildmat. For example:
情報には、ニュースグループベースであり、そしてWILDMAT応答が名前WILDMATに一致のみのグループ（存在する場合）に制限される場合には、指定されてもよいです。例えば：
[C] LIST ACTIVE *.recovery [S] 215 list of newsgroups follows [S] alt.rfc-writers.recovery 4 1 y [S] tx.natives.recovery 89 56 y [S] .
[C] LIST ACTIVE *ニュースグループの.recovery [S] 215のリストは、以下の[S] alt.rfc-writers.recovery 4 1 Y [S] tx.natives.recovery 89 56 Y [S]。
This keyword is optional.
このキーワードはオプションです。
The active.times list is maintained by some NNTP servers to contain information about who created a particular newsgroup and when. Each line of this list consists of three fields separated from each other by one or more spaces. The first field is the name of the newsgroup. The second is the time when this group was created on this news server, measured in seconds since the start of January 1, 1970. The third is plain text intended to describe the entity that created the newsgroup; it is often a mailbox as defined in RFC 2822 [RFC2822]. For example:
active.timesリストはときに、特定のニュースグループを作成し、誰についての情報を含むために、いくつかのNNTPサーバによって維持されています。このリストの各行は、1つ以上のスペースによって互いから分離された3つのフィールドから構成されています。最初のフィールドは、ニュースグループの名前です。第二は、第三は、ニュースグループを作成したエンティティを説明することを意図してプレーンテキストである1970年1月1日の開始以来、秒単位で測定され、このグループは、このニュースサーバー上に作成された時刻です。 RFC 2822 [RFC2822]で定義されていることは、多くの場合、メールボックスです。例えば：
[C] LIST ACTIVE.TIMES [S] 215 information follows [S] misc.test 930445408 <creatme@isc.org> [S] alt.rfc-writers.recovery 930562309 <m@example.com> [S] tx.natives.recovery 930678923 <sob@academ.com> [S] .
[C] LISTは、[S] 215の情報は、以下の[S] misc.test 930445408 <creatme@isc.org> [S] alt.rfc-writers.recovery 930562309 <m@example.com> [S] TXをACTIVE.TIMES。 natives.recovery 930678923 <sob@academ.com> [S]。
The list MAY omit newsgroups for which the information is unavailable and MAY include groups not available on the server; in particular, it MAY omit all groups created before the date and time of the oldest entry. The client MUST NOT assume that the list is complete or that it matches the list returned by the LIST ACTIVE command (Section 7.6.3). The NEWGROUPS command (Section 7.3) may provide a better way to access this information, and the results of the two commands SHOULD be consistent except that, if the latter is invoked with a date and time earlier than the oldest entry in active.times list, its result may include extra groups.
リストには、情報が利用できないと、サーバー上で利用できないグループを含むことができるためにニュースグループを省略してもよい（MAY）。特に、それは最も古いエントリの日付と時刻以前に作成されたすべてのグループを省略することができます。クライアントは、リストが完了したか、それはLIST ACTIVEコマンド（セクション7.6.3）によって返されたリストに一致していることと仮定してはいけません。 NEWGROUPSコマンド（7.3節）は、この情報にアクセスするためのより良い方法を提供することができ、後者はactive.timesリスト内の最も古いエントリより前の日時で呼び出された場合の二つのコマンドの結果は、それ以外は一貫しているべきです、その結果は、余分な基を含んでもよいです。
The information is newsgroup based, and a wildmat MAY be specified, in which case the response is limited to only the groups (if any) whose names match the wildmat.
情報には、ニュースグループベースであり、そしてWILDMAT応答が名前WILDMATに一致のみのグループ（存在する場合）に制限される場合には、指定されてもよいです。
This keyword is optional.
このキーワードはオプションです。
The distrib.pats list is maintained by some NNTP servers to assist clients to choose a value for the content of the Distribution header of a news article being posted. Each line of this list consists of three fields separated from each other by a colon (":"). The first field is a weight, the second field is a wildmat (which may be a simple newsgroup name), and the third field is a value for the Distribution header content. For example:
distrib.patsリストが掲載されているニュース記事の配信ヘッダの内容の値を選択するようにクライアントを支援するために、いくつかのNNTPサーバによって維持されています。このリストの各行は、コロンによって互いから分離された3つのフィールド（「：」）からなります。最初のフィールドは、第2のフィールドは、（単純なニュースグループ名であってもよい）WILDMATで、重量であり、そして第3のフィールドは、分配ヘッダコンテンツの値です。例えば：
[C] LIST DISTRIB.PATS [S] 215 information follows [S] 10:local.*:local [S] 5:*:world [S] 20:local.here.*:thissite [S] .
[C]のリストDISTRIB.PATSは、[S] 215の情報は、以下の[S] 10：ローカル*：ローカル[S] 5：*：世界[S] 20：local.here *：thissite [S]。
The client MAY use this information to construct an appropriate Distribution header given the name of a newsgroup. To do so, it should determine the lines whose second field matches the newsgroup name, select from among them the line with the highest weight (with 0 being the lowest), and use the value of the third field to construct the Distribution header.
クライアントは、ニュースグループの名前を指定された適切な分配ヘッダを構築するためにこの情報を使用することができます。そうするために、それは、その第2のフィールドニュースグループ名と一致する行を決定し、それらの中から（0が最低である）最高の重みの行を選択し、分配ヘッダを構築する第3のフィールドの値を使用すべきです。
The information is not newsgroup based, and an argument MUST NOT be specified.
情報は、ニュースグループベースではなく、引数が指定することはできません。
This keyword MUST be supported by servers advertising the READER capability.
このキーワードは、READER機能を公示サーバでサポートしなければなりません。
The newsgroups list is maintained by NNTP servers to contain the name of each newsgroup that is available on the server and a short description about the purpose of the group. Each line of this list consists of two fields separated from each other by one or more space or TAB characters (the usual practice is a single TAB). The first field is the name of the newsgroup, and the second is a short description of the group. For example:
ニュースグループのリストは、サーバーやグループの目的についての簡単な説明で提供され、各ニュースグループの名前を含むようにNNTPサーバによって維持されています。このリストの各行は、一つ以上のスペースまたはタブ文字（通常の実施は、単一のタブである）によって互いから分離された二つのフィールドから構成されています。最初のフィールドは、ニュースグループの名前であり、そして第二のグループの簡単な説明です。例えば：
[C] LIST NEWSGROUPS [S] 215 information follows [S] misc.test General Usenet testing [S] alt.rfc-writers.recovery RFC Writers Recovery [S] tx.natives.recovery Texas Natives Recovery [S] .
[C] LISTニュースグループ[S] 215の情報は、以下の[S] misc.test一般Usenetのテスト[S] alt.rfc-writers.recoveryのRFC作家回復[S] tx.natives.recoveryテキサスの原住民の回復[S]。
The list MAY omit newsgroups for which the information is unavailable and MAY include groups not available on the server. The client MUST NOT assume that the list is complete or that it matches the list returned by LIST ACTIVE.
リストには、情報が利用できないと、サーバー上で利用できないグループを含むことができるためにニュースグループを省略することができます。クライアントは、リストが完了したか、それはACTIVE LISTによって返されたリストに一致していることと仮定してはいけません。
The description SHOULD be in UTF-8. However, servers often obtain the information from external sources. These sources may have used different encodings (ones that use octets in the range 128 to 255 in some other manner) and, in that case, the server MAY pass it on unchanged. Therefore, clients MUST be prepared to receive such descriptions.
説明はUTF-8にする必要があります。ただし、サーバーは、多くの場合、外部ソースからの情報を得ます。これらのソースは、異なるエンコーディング（他の方法で255の範囲128内のオクテットを使用するもの）を使用している可能性があり、その場合には、サーバーは変更されずにそれを渡すことができます。そのため、クライアントは、そのような記述を受け取るために準備しなければなりません。
The information is newsgroup based, and a wildmat MAY be specified, in which case the response is limited to only the groups (if any) whose names match the wildmat.
情報には、ニュースグループベースであり、そしてWILDMAT応答が名前WILDMATに一致のみのグループ（存在する場合）に制限される場合には、指定されてもよいです。
This section lists commands that may be used to access specific article fields; that is, headers of articles and metadata about articles. These commands typically fetch data from an "overview database", which is a database of headers extracted from incoming articles plus metadata determined as the article arrives. Only certain fields are included in the database.
このセクションでは、特定の記事のフィールドにアクセスするために使用できるコマンドを示します。それは、記事についての記事やメタデータのヘッダです。これらのコマンドは、通常、物品が到着するように決定入ってくる記事に加えて、メタデータから抽出されたヘッダのデータベースである「概要データベース」からデータをフェッチします。のみ特定のフィールドは、データベースに含まれています。
This section is based on the Overview/NOV database [ROBE1995] developed by Geoff Collyer.
このセクションは、[ROBE1995]ジェフ・コルヤーによって開発された概要/ 11月データベースに基づいています。
Article "metadata" is data about articles that does not occur within the article itself. Each metadata item has a name that MUST begin with a colon (and that MUST NOT contain a colon elsewhere within it). As with header names, metadata item names are not case sensitive.
記事「メタデータ」は、物品自体の中で発生していない記事に関するデータです。各メタデータ項目はコロンで始まる必要があります（とそれはそれ内の他の場所にコロンを含めることはできません）の名前を持っています。ヘッダ名と同様に、メタデータ項目名は、大文字と小文字が区別されません。
When generating a metadata item, the server MUST compute it for itself and MUST NOT trust any related value provided in the article. (In particular, a Lines or Bytes header in the article MUST NOT be assumed to specify the correct number of lines or bytes in the article.) If the server has access to several non-identical copies of an article, the value returned MUST be correct for any copy of that article retrieved during the same session.
メタデータ項目を生成する場合、サーバーは、自身のためにそれを計算しなければなりませんし、資料に記載されている、すべての関連する値を信用してはいけません。 （具体的には、物品内の行数またはバイトヘッダが記事の行または正しいバイト数を指定すると仮定してはいけません。）サーバは、物品のいくつかの非同一のコピーへのアクセスを有する場合、値がなければなりません返さ同じセッション中に取得したその記事のコピーを修正します。
This specification defines two metadata items: ":bytes" and ":lines". Other metadata items may be defined by extensions. The names of metadata items defined by registered extensions MUST NOT begin with ":x-". To avoid the risk of a clash with a future registered extension, the names of metadata items defined by private extensions SHOULD begin with ":x-".
この仕様は、2つのメタデータアイテム定義：「バイト」と「行」。その他のメタデータ項目は、拡張によって定義することができます。 「：X-」登録機能拡張によって定義されたメタデータ項目の名前がで始めてはいけません。 「：X-」未来の登録拡張子との衝突の危険を回避するために、民間の拡張機能によって定義されたメタデータ項目の名前はで開始する必要があります。
The :bytes metadata item for an article is a decimal integer. It SHOULD equal the number of octets in the entire article: headers, body, and separating empty line (counting a CRLF pair as two octets, and excluding both the "." CRLF terminating the response and any "." added for "dot-stuffing" purposes).
：記事のバイトメタデータ項目が10進整数です。これは、物品全体のオクテットの数に等しくなければならない：ヘッダ、本体、および空行（2つのオクテットとしてCRLFペアをカウントを分離し、除く両方CRLF応答と任意の終端ドット - 「を追加「」を「」詰め物」の目的）。
Note to client implementers: some existing servers return a value different from that above. The commonest reasons for this are as follows:
クライアントの実装者への注意：いくつかの既存のサーバーは、その上から別の値を返します。これは、次のような最も一般的な理由は、次のとおりです。
o Counting a CRLF pair as one octet.
1つのオクテットとしてCRLFペアをカウントO。
o Including the "." character used for dot-stuffing in the number.
Oを含みます「」数のドット詰め物に使用する文字。
o Including the terminating "." CRLF in the number.
終端を含むO「」数のCRLF。
o Using one copy of an article for counting the octets but then returning another one that differs in some (permitted) manner.
オクテットを数えるが、その後、いくつかの（許可）の方法が異なる別のものを返すため、物品の一つのコピーを使用して、O。
Implementations should be prepared for such variation and MUST NOT rely on the value being accurate.
実装は、このような変化のために準備しなければならないと正確である値に依存してはなりません。
The :lines metadata item for an article is a decimal integer. It MUST equal the number of lines in the article body (excluding the empty line separating headers and body). Equivalently, it is two less than the number of CRLF pairs that the BODY command would return for that article (the extra two are those following the response code and the termination octet).
：記事の行のメタデータ項目は、10進数の整数です。これは、（ヘッダとボディを分離する空行を除く）記事本文の行数と等しくなければなりません。同等に、それはBODYコマンドは、その記事のために戻ってくるCRLFペアの数より2少ないです（追加2は、応答コードと終端オクテット以下のものです）。
The information stored in the overview database may change over time. If the database records the content or absence of a given field (that is, a header or metadata item) for all articles, it is said to be "consistent" for that field. If it records the content of a header for some articles but not for others that nevertheless included that header, or if it records a metadata item for some articles but not for others to which that item applies, it is said to be "inconsistent" for that field.
概要データベースに格納されている情報は、時間の経過とともに変化することがあります。データベースは、すべての記事のために指定されたフィールドの内容または非存在下（すなわち、ヘッダまたはメタデータ項目である）を記録する場合は、そのフィールドの「一貫性」であると言われます。それはいくつかの記事のためではなく、それにもかかわらず、そのヘッダーを含めるか、それはいくつかの記事のためではなく、その項目が適用される他のメタデータ項目を記録した場合、のための「矛盾」と言われている他の人のためのヘッダの内容を記録している場合そのフィールド。
The LIST OVERVIEW.FMT command SHOULD list all the fields for which the database is consistent at that moment. It MAY omit such fields (for example, if it is not known whether the database is consistent or inconsistent). It MUST NOT include fields for which the database is inconsistent or that are not stored in the database. Therefore, if a header appears in the LIST OVERVIEW.FMT output but not in the OVER output for a given article, that header does not appear in the article (similarly for metadata items).
LISTのOVERVIEW.FMTコマンドは、データベースがその時点で一致しているため、すべてのフィールドをリストする必要があります。 （データベースが整合または不整合であるかどうかは知られていない場合など）には、そのようなフィールドを省略することができます。これは、データベースが矛盾しているか、それはデータベースに格納されていないためにフィールドを含めることはできません。したがって、ヘッダは、リストOVERVIEW.FMT出力に現れるが、所与の物品のためのOVER出力において、そのヘッダが（同様にメタデータ項目のための）資料に表示されないではない。場合
These rules assume that the fields being stored in the database remain constant for long periods of time, and therefore the database will be consistent. When the set of fields to be stored is changed, it will be inconsistent until either the database is rebuilt or the only articles remaining are those received since the change. Therefore, the output from LIST OVERVIEW.FMT needs to be altered twice. Firstly, before any fields stop being stored they MUST be removed from the output; then, when the database is once more known to be consistent, the new fields SHOULD be added to the output.
これらの規則は、データベースに格納されているフィールドは、長期間にわたって一定のままで、したがってデータベースが整合されると仮定します。格納されるフィールドのセットが変更されたときにデータベースのいずれかが再構築されるか、または残りの記事だけが変化するので、受信したものになるまで、それは矛盾であろう。したがって、必要OVERVIEW.FMT LISTからの出力は、二回変更します。任意のフィールドが格納されて停止する前に、まず、それらは出力から除去されなければなりません。データベースは一度より一貫性であることが知られているときに、新しいフィールドが出力に追加する必要があります。
If the HDR command uses the overview database rather than taking information directly from the articles, the same issues of consistency and inconsistency apply, and the LIST HEADERS command SHOULD take the same approach as the LIST OVERVIEW.FMT command in resolving them.
HDRコマンドは、記事から直接情報を取るのではなく、概要データベースを使用する場合は、一貫性と矛盾の同じ問題が適用され、およびLISTヘッダコマンドは、それらを解決するためのLISTのOVERVIEW.FMTコマンドと同じアプローチを取る必要があります。
Indicating capability: OVER
示す機能：OVER
Syntax OVER message-id OVER range OVER
メッセージID OVER構文OVER OVER範囲
Responses
反応
First form (message-id specified) 224 Overview information follows (multi-line) 430 No article with that message-id
（メッセージIDが指定された）最初のフォーム224の概要情報は、以下の（マルチライン）は、メッセージIDを持つ430なし記事
Second form (range specified) 224 Overview information follows (multi-line) 412 No newsgroup selected 423 No articles in that range
第二の形態（範囲指定）224の概要情報は、（マルチライン）以下の412なしニュースグループは、その範囲内の423件のなしの記事を選択していません
Third form (current article number used) 224 Overview information follows (multi-line) 412 No newsgroup selected 420 Current article number is invalid
第三の形態（現在使用されている文書番号）224の概要情報は、以下の（マルチライン）412なしニュースグループは420現在の文書番号が無効で選択されていません
Parameters range Number(s) of articles message-id Message-id of article
記事の記事のメッセージIDのメッセージIDのパラメータの範囲の番号（S）
The OVER command returns the contents of all the fields in the database for an article specified by message-id, or from a specified article or range of articles in the currently selected newsgroup.
OVERコマンドは、現在選択ニュースグループ内の物品の指定された物品又は範囲からメッセージIDで指定された記事のデータベース内のすべてのフィールドの内容を返します。
The message-id argument indicates a specific article. The range argument may be any of the following:
メッセージ-id引数は、特定の記事を示します。範囲引数は、次のいずれであってもよいです。
o An article number.
資料番号O。
o An article number followed by a dash to indicate all following.
以下のすべてを示すためにダッシュが続くの資料番号O。
o An article number followed by a dash followed by another article number.
Oの資料番号は、別の記事の番号が続くダッシュが続きます。
If neither is specified, the current article number is used.
どちらも指定されている場合は、現在の記事番号が使用されています。
Support for the first (message-id) form is optional. If it is supported, the OVER capability line MUST include the argument "MSGID". Otherwise, the capability line MUST NOT include this argument, and the OVER command MUST return the generic response code 503 when this form is used.
最初の（メッセージID）形式のサポートはオプションです。それがサポートされている場合は、OVER機能ライン引数「MSGID」を含まなければなりません。それ以外の場合は、能力ラインは、この引数を含んではいけませんし、このフォームを使用する場合OVERコマンドは、一般的な応答コード503を返さなければなりません。
If the information is available, it is returned as a multi-line data block following the 224 response code and contains one line per article, sorted in numerical order of article number. (Note that unless the argument is a range including a dash, there will be exactly one line in the data block.) Each line consists of a number of fields separated by a TAB. A field may be empty (in which case there will be two adjacent TABs), and a sequence of trailing TABs may be omitted.
情報が利用可能である場合、それは224応答コード次のマルチラインのデータブロックとして戻され、文書番号の番号順にソートされ、物品ごとに行を含みます。 （引数がダッシュを含む範囲でなければ、データブロック内に正確に一つのラインが存在するであろうことに留意されたい。）各行は、タブで区切られたフィールドの数で構成されています。フィールドは、（この場合は、2つの隣接するタブが存在するであろう）が空であってもよく、後続のタブシーケンスを省略してもよいです。
The first 8 fields MUST be the following, in order:
最初の8つのフィールドは、次の順序でのでなければなりません。
"0" or article number (see below) Subject header content From header content Date header content Message-ID header content References header content :bytes metadata item :lines metadata item
バイトメタデータ項目：行メタデータアイテムヘッダコンテンツ日ヘッダコンテンツメッセージ-IDヘッダのコンテンツ参照がコンテンツをヘッダから「0」または資料番号（下記参照）テーマヘッダコンテンツ
If the article is specified by message-id (the first form of the command), the article number MUST be replaced with zero, except that if there is a currently selected newsgroup and the article is present in that group, the server MAY use the article's number in that group. (See the ARTICLE command (Section 6.2.1) and STAT examples (Section 6.2.4.3) for more details.) In the other two forms of the command, the article number MUST be returned.
物品は、メッセージID（コマンドの最初の形式）によって指定されている場合が現在選択されているニュースグループであり、物品がそのグループに存在する場合、サーバが使用できることを除いて、文書番号は、ゼロに置き換える必要がありますそのグループ内の記事の数。 （詳細については、ARTICLEコマンド（6.2.1項）及びSTAT例（セクション6.2.4.3）を参照。）、コマンドの他の2つの形態で、文書番号が返されなければなりません。
Any subsequent fields are the contents of the other headers and metadata held in the database.
後続のフィールドは、データベースに保持されている他のヘッダとメタデータの内容です。
For the five mandatory headers, the content of each field MUST be based on the content of the header (that is, with the header name and following colon and space removed). If the article does not contain that header, or if the content is empty, the field MUST be empty. For the two mandatory metadata items, the content of the field MUST be just the value, with no other text.
5つの必須のヘッダの各フィールドの内容（すなわち、ヘッダ名と次のコロンとスペースを除去して、である）ヘッダの内容に基づいていなければなりません。記事では、そのヘッダーが含まれていない場合、またはコンテンツが空の場合、フィールドが空である必要があります。 2つの必須のメタデータ項目について、フィールドの内容は他のテキストと値だけ、でなければなりません。
For all subsequent fields that contain headers, the content MUST be the entire header line other than the trailing CRLF. For all subsequent fields that contain metadata, the field consists of the metadata name, a single space, and then the value.
ヘッダを含む後続のすべてのフィールドに、コンテンツは、後続CRLF以外の全体ヘッダー行でなければなりません。メタデータを含むすべての後続フィールドの場合、フィールドには、メタデータ名、単一のスペース、およびその値で構成されています。
For all fields, the value is processed by first removing all CRLF pairs (that is, undoing any folding and removing the terminating CRLF) and then replacing each TAB with a single space. If there is no such header in the article, no such metadata item, or no header or item stored in the database for that article, the corresponding field MUST be empty.
すべてのフィールドに、値は、最初に、すべてのCRLFペアを除去（即ち、任意の折り畳みを元に戻すと終端CRLFを除去）した後、単一のスペースで各タブを置き換えることによって処理されます。物品、そのようなメタデータ項目、またはその記事のデータベースに格納されないヘッダまたは項目には、そのようなヘッダが存在しない場合、対応するフィールドは空でなければなりません。
Note that, after unfolding, the characters NUL, LF, and CR cannot occur in the header of an article offered by a conformant server. Nevertheless, servers SHOULD check for these characters and replace each one by a single space (so that, for example, CR LF LF TAB will become two spaces, since the CR and first LF will be removed by the unfolding process). This will encourage robustness in the face of non-conforming data; it is also possible that future versions of this specification could permit these characters to appear in articles.
展開後、文字NUL、LF、およびCRが準拠サーバによって提供される記事のヘッダで発生することができない、ということに注意してください。それにもかかわらず、サーバは、（CR第LFが展開プロセスによって除去されるので、例えば、CR LF LF TABは、二つの空間となるであろうように）これらの文字を確認し、単一のスペースでそれぞれを交換してください。これは、非準拠したデータの顔で堅牢性を奨励します。この仕様の将来のバージョンは、記事に表示されるようにこれらの文字を許可する可能性もあります。
The server SHOULD NOT produce output for articles that no longer exist.
サーバーは、もはや存在しない記事のための出力を生成すべきではありません。
If the argument is a message-id and no such article exists, a 430 response MUST be returned. If the argument is a range or is omitted and the currently selected newsgroup is invalid, a 412 response MUST be returned. If the argument is a range and no articles in that number range exist in the currently selected newsgroup, including the case where the second number is less than the first one, a 423 response MUST be returned. If the argument is omitted and the current article number is invalid, a 420 response MUST be returned.
引数は、メッセージIDであり、そのような物品が存在しない場合、430応答が返されなければなりません。引数が範囲であるか、または省略され、現在選択されているニュースグループが無効である場合、412応答が返されなければなりません。引数が二番目の数字は、最初の1未満である場合を含めて、現在選択されているニュースグループの範囲とその数の範囲内でない記事が存在している場合、423応答が返されなければなりません。引数を省略すると、現在の記事番号が無効となる場合は、420応答が返されなければなりません。
In the first four examples, TAB has been replaced by vertical bar and some lines have been folded for readability.
最初の4つの例では、TABは、垂直バーに置き換えられましたし、いくつかの行は読みやすいように折り畳まれています。
Example of a successful retrieval of overview information for an article (explicitly not using an article number):
物品（明示的に文書番号を使用していない）の概要情報の成功した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] OVER [S] 224 Overview information follows [S] 3000234|I am just a test article|"Demo User" <nobody@example.com>|6 Oct 1998 04:38:40 -0500| <45223423@example.com>|<45454@example.net>|1234| 17|Xref: news.example.com misc.test:3000363 [S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [S] 224概要情報は、以下の[S] 3000234 OVER [C] |私はちょうど試験物品午前| "デモ・ユーザー" <nobody@example.com > | 1998年10月6日4時38分40秒-0500 | <45223423@example.com> | <45454@example.net> | 1234年| 17 |外部参照：news.example.com misc.test：3000363 [のS]。
Example of a successful retrieval of overview information for an article by message-id:
メッセージIDの論文の概要情報の成功した検索の例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] OVER MSGID [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT [S] . [C] OVER <45223423@example.com> [S] 224 Overview information follows [S] 0|I am just a test article|"Demo User" <nobody@example.com>|6 Oct 1998 04:38:40 -0500| <45223423@example.com>|<45454@example.net>|1234| 17|Xref: news.example.com misc.test:3000363 [S] .
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] OVER MSGID [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT [S]。 [C] <45223423@example.com> OVER [S] 224概要情報は、以下の[S] 0 |私はちょうど試験物品午前| "デモ・ユーザー" <nobody@example.com> | 1998年10月6日4時38分40秒-0500 | <45223423@example.com> | <45454@example.net> | 1234年| 17 |外部参照：news.example.com misc.test：3000363 [のS]。
Note that the article number has been replaced by "0".
資料番号は「0」に置き換えられていることに注意してください。
Example of the same commands on a system that does not implement retrieval by message-id:
メッセージIDにより検索を実装していないシステム上の同じコマンドの例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] OVER [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT [S] . [C] OVER <45223423@example.com> [S] 503 Overview by message-id unsupported
[C] CAPABILITIES [S] 101の能力リスト：[S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT [S] OVER [S] VERSION 2 [S] READER [S]。 [C] OVER <45223423@example.com> [S] 503の概要メッセージIDによってサポートされていません
Example of a successful retrieval of overview information for a range of articles:
記事の範囲の概要情報の成功した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] OVER 3000234-3000240 [S] 224 Overview information follows [S] 3000234|I am just a test article|"Demo User" <nobody@example.com>|6 Oct 1998 04:38:40 -0500| <45223423@example.com>|<45454@example.net>|1234| 17|Xref: news.example.com misc.test:3000363 [S] 3000235|Another test article|nobody@nowhere.to (Demo User)|6 Oct 1998 04:38:45 -0500|<45223425@to.to>|| 4818|37||Distribution: fi [S] 3000238|Re: I am just a test article|somebody@elsewhere.to| 7 Oct 1998 11:38:40 +1200|<kfwer3v@elsewhere.to>| <45223423@to.to>|9234|51 [S] .
私はちょうどテスト品だ| | 3000234から3000240 OVER [C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] [S] 224概要情報は、[S] 3000234次の "デモ・ユーザー" <誰もが@ example.com> | 1998年10月6日午前4時38分40秒-0500 | <45223423@example.com> | <45454@example.net> | 1234年| 17 |外部参照：news.example.com misc.test：3000363 [S] 3000235 |別のテストarticle|nobody@nowhere.to（デモユーザー）| 1998年10月6日午前4時38分45秒-0500 | <45223425@to.to > || 4818 | 37 ||分布：Fiの[S] 3000238 |日時：私はちょうど試験物品午前| somebody@elsewhere.to | 1998年10月7日11時38分40秒1200 | <kfwer3v@elsewhere.to> | <45223423@to.to> | 9234 | 51 [S]。
Note the missing "References" and Xref headers in the second line, the missing trailing fields in the first and last lines, and that there are only results for those articles that still exist.
、2行目の欠けている「参照」と外部参照のヘッダーに注意してください最初と最後の行で行方不明末尾のフィールド、そしてまだ存在し、それらの記事のための唯一の結果があること。
Example of an unsuccessful retrieval of overview information on an article by number:
数による記事の概要情報の失敗した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] OVER 300256 [S] 423 No such article in this group
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] 300256 OVER [S] 423このグループには、そのような物品
Example of an invalid range:
無効な範囲の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] OVER 3000444-3000222 [S] 423 Empty range
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] 3000444-3000222 OVER [S] 423空範囲
Example of an unsuccessful retrieval of overview information by number because no newsgroup was selected first:
数によって概要情報の失敗した検索の例ないニュースグループが最初に選択されなかったため。
[Assumes currently selected newsgroup is invalid.] [C] OVER [S] 412 No newsgroup selected
[現在選択されているニュースグループが無効であると仮定。] [C]いいえニュースグループ選択412 [S] OVER
Example of an attempt to retrieve information when the currently selected newsgroup is empty:
現在選択されているニュースグループが空のときに情報を取得しようとする試みの例：
[C] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] OVER [S] 420 No current article selected
選択された[S] 420なし現在の記事OVER [C]グループexample.empty.newsgroup [S] 211 0 0 example.empty.newsgroup [C]
Indicating capability: OVER
示す機能：OVER
Syntax LIST OVERVIEW.FMT
構文LIST OVERVIEW.FMT
Responses 215 Information follows (multi-line)
215の情報は、以下の回答（複数行）
See Section 7.6.1 for general requirements of the LIST command.
LISTコマンドの一般的な要件については、セクション7.6.1を参照してください。
The LIST OVERVIEW.FMT command returns a description of the fields in the database for which it is consistent (as described above). The information is returned as a multi-line data block following the 215 response code. The information contains one line per field in the order in which they are returned by the OVER command; the first 7 lines MUST (except for the case of letters) be exactly as follows:
LISTのOVERVIEW.FMTコマンドは、（上記のように）一致されているデータベース内のフィールドの説明を返します。情報は、215応答コード次のマルチラインのデータブロックとして返されます。情報は、彼らがOVERコマンドによって返される順番で、フィールドごとに1行が含まれています。次のようにしなければならない（文字の場合を除く）最初の7行は正確です。
Subject:
From:
Date:
Message-ID:
References:
:bytes
:lines
For compatibility with existing implementations, the last two lines MAY instead be:
既存の実装との互換性のため、最後の2行ではなくなることがあります。
Bytes:
Lines:
even though they refer to metadata, not headers.
彼らは、メタデータ、ないヘッダを参照してくださいにもかかわらず。
All subsequent lines MUST consist of either a header name followed by ":full", or the name of a piece of metadata.
「フル」以降のすべての行が続くヘッダ名のいずれかで構成する必要があり、メタデータの一部の名前。
There are no leading or trailing spaces in the output.
出力には先頭または末尾にスペースがありません。
Note that the 7 fixed lines describe the 2nd to 8th fields of the OVER output. The "full" suffix (which may use either uppercase, lowercase, or a mix) is a reminder that the corresponding fields include the header name.
7本の固定線はOVER出力の8分野に2を記述することに注意してください。 （大文字、小文字、または混合して用いることができる）「フル」サフィックスは、対応するフィールドがヘッダ名を含むことが通知されます。
This command MAY generate different results if it is used more than once in a session.
それは、セッション内で複数回使用されている場合、このコマンドは、異なる結果を生成することがあります。
If the OVER command is not implemented, the meaning of the output from this command is not specified, but it must still meet the above syntactic requirements.
OVERコマンドが実装されていない場合は、このコマンドの出力の意味が指定されていないが、それはまだ上記の構文上の要件を満たす必要があります。
Example of LIST OVERVIEW.FMT output corresponding to the example OVER output above, in the preferred format:
LISTのOVERVIEW.FMT出力の例は、好ましい形式では、上記出力OVER例に対応します。
[C] LIST OVERVIEW.FMT [S] 215 Order of fields in overview database. [S] Subject: [S] From: [S] Date: [S] Message-ID: [S] References: [S] :bytes [S] :lines [S] Xref:full [S] Distribution:full [S] .
[C] LIST OVERVIEW.FMT [S]概要データベース内のフィールドの215オーダー。 [S]件名：[S]から：[S]日付：[S]のMessage-ID：[S]参考文献：[S]：バイト[S]：線[S]外部参照：フル[S]の分布：フル[ S]。
Example of LIST OVERVIEW.FMT output corresponding to the example OVER output above, in the alternative format:
LISTのOVERVIEW.FMT出力の例は、別のフォーマットでは、上記出力OVER例に対応します。
[C] LIST OVERVIEW.FMT [S] 215 Order of fields in overview database. [S] Subject: [S] From: [S] Date: [S] Message-ID: [S] References: [S] Bytes: [S] Lines: [S] Xref:FULL [S] Distribution:FULL [S] .
[C] LIST OVERVIEW.FMT [S]概要データベース内のフィールドの215オーダー。 [S]件名：[S]から：[S]日付：[S]のMessage-ID：[S]参考文献：[S]バイト：[S]行：[S]外部参照：FULL [S]の分布：[FULL S]。
Indicating capability: HDR
示す機能：HDR
Syntax HDR field message-id HDR field range HDR field
構文HDRフィールドメッセージID HDRフィールドの範囲HDRフィールド
Responses
反応
First form (message-id specified) 225 Headers follow (multi-line) 430 No article with that message-id
最初の形式（メッセージIDが指定された）225のヘッダは、（複数行）に従う430そのメッセージIDとは、物品
Second form (range specified) 225 Headers follow (multi-line) 412 No newsgroup selected 423 No articles in that range
第二の形態（範囲指定）225のヘッダは、（複数行）に従う412なしニュースグループは、その範囲内の423件のなしの記事を選択していません
Third form (current article number used) 225 Headers follow (multi-line) 412 No newsgroup selected 420 Current article number is invalid
第三の形態（現在使用されている文書番号）225のヘッダが続く（マルチライン）412なしニュースグループは420現在の文書番号が無効で選択されていません
Parameters field Name of field range Number(s) of articles message-id Message-id of article
記事のメッセージIDのメッセージID記事のフィールドの範囲の番号（S）のパラメータフィールド名
The HDR command provides access to specific fields from an article specified by message-id, or from a specified article or range of articles in the currently selected newsgroup. It MAY take the information directly from the articles or from the overview database. In the case of headers, an implementation MAY restrict the use of this command to a specific list of headers or MAY allow it to be used with any header; it may behave differently when it is used with a message-id argument and when it is used with a range or no argument.
HDRコマンドは、メッセージIDによって指定された物品から、または現在選択されているニュースグループ内の記事の指定物品又は範囲から特定のフィールドへのアクセスを提供します。これは、記事からまたは概要データベースから直接情報がかかる場合があります。ヘッダの場合、実装は、ヘッダの特定のリストには、このコマンドの使用を制限することができるか、それが任意のヘッダで使用することを可能にすることができます。それはメッセージID引数で使用される場合、それは範囲または引数なしで使用する場合には、異なる動作をすることができます。
The required field argument is the name of a header with the colon omitted (e.g., "subject") or the name of a metadata item including the leading colon (e.g., ":bytes"), and is case insensitive.
必須フィールド引数はコロン省略（例えば、「被験体」）、または主要結腸を含むメタデータ項目の名前を持つヘッダの名前（例えば、「：バイト」）、および大文字と小文字を区別しないです。
The message-id argument indicates a specific article. The range argument may be any of the following:
メッセージ-id引数は、特定の記事を示します。範囲引数は、次のいずれであってもよいです。
o An article number.
資料番号O。
o An article number followed by a dash to indicate all following.
以下のすべてを示すためにダッシュが続くの資料番号O。
o An article number followed by a dash followed by another article number.
Oの資料番号は、別の記事の番号が続くダッシュが続きます。
If neither is specified, the current article number is used.
どちらも指定されている場合は、現在の記事番号が使用されています。
If the information is available, it is returned as a multi-line data block following the 225 response code and contains one line for each article in the range that exists. (Note that unless the argument is a range including a dash, there will be exactly one line in the data block.) The line consists of the article number, a space, and then the contents of the field. In the case of a header, the header name, the colon, and the first space after the colon are all omitted.
情報が利用可能である場合、それは225応答コード次の複数行のデータブロックとして戻され、存在する範囲内の各記事のための1つの行が含まれています。 （引数がダッシュを含む範囲でなければ、データブロック内に正確に一つのラインが存在するであろうことに留意されたい。）ラインは、文書番号、スペース、およびフィールドのその後の内容で構成されています。ヘッダの場合には、ヘッダ名、コロン、コロンの後の最初のスペースはすべて省略されています。
If the article is specified by message-id (the first form of the command), the article number MUST be replaced with zero, except that if there is a currently selected newsgroup and the article is present in that group, the server MAY use the article's number in that group. (See the ARTICLE command (Section 6.2.1) and STAT examples (Section 6.2.4.3) for more details.) In the other two forms of the command, the article number MUST be returned.
物品は、メッセージID（コマンドの最初の形式）によって指定されている場合が現在選択されているニュースグループであり、物品がそのグループに存在する場合、サーバが使用できることを除いて、文書番号は、ゼロに置き換える必要がありますそのグループ内の記事の数。 （詳細については、ARTICLEコマンド（6.2.1項）及びSTAT例（セクション6.2.4.3）を参照。）、コマンドの他の2つの形態で、文書番号が返されなければなりません。
Header contents are modified as follows: all CRLF pairs are removed, and then each TAB is replaced with a single space. (Note that this is the same transformation as is performed by the OVER command (Section 8.3.2), and the same comment concerning NUL, CR, and LF applies.)
全てCRLF対が除去され、その後、各タブは単一のスペースに置き換えられる：ヘッダの内容は、以下のように修正されます。 （これはオーバーコマンド（8.3.2項）によって行われ、NUL、CRに関する同じコメント、及びLFが適用されるのと同じ変換であることに注意してください。）
Note the distinction between headers and metadata appearing to have the same meaning. Headers are always taken unchanged from the article; metadata are always calculated. For example, a request for "Lines" returns the contents of the "Lines" header of the specified articles, if any, no matter whether they accurately state the number of lines, while a request for ":lines" returns the line count metadata, which is always the actual number of lines irrespective of what any header may state.
同じ意味を持つように見えるヘッダとメタデータの区別に注意してください。ヘッダは常に、記事からそのまま取らされています。メタデータは、常に計算されます。 「：ライン」ラインカウントメタデータを返す任意の場合たとえば、「行」の要求は、要求がいる間、彼らは正確に、行数を述べるかどうかに関係なく、指定された記事の「行」ヘッダの内容を返します。 、にかかわらず、任意のヘッダを述べることができるものの行の実際の数は常にあります。
If the requested header is not present in the article, or if it is present but empty, a line for that article is included in the output, but the header content portion of the line is empty (the space after the article number MAY be retained or omitted). If the header occurs in a given article more than once, only the content of the first occurrence is returned by HDR. If any article number in the provided range does not exist in the group, no line for that article number is included in the output.
要求されたヘッダは、物品中に存在しない、またはそれが存在するが空の場合、その物品のためのラインが出力に含まれるが、ラインのヘッダのコンテンツ部分が空である（資料番号の後にスペースを保持することができる場合または）省略。ヘッダは複数回指定された資料に発生した場合、最初の発生のコンテンツのみがHDRによって返されます。提供される範囲内の任意の文書番号がグループに存在しない場合、その文書番号のためのラインが出力に含まれていません。
If the second argument is a message-id and no such article exists, a 430 response MUST be returned. If the second argument is a range or is omitted and the currently selected newsgroup is invalid, a 412 response MUST be returned. If the second argument is a range and no articles in that number range exist in the currently selected newsgroup, including the case where the second number is less than the first one, a 423 response MUST be returned. If the second argument is omitted and the current article number is invalid, a 420 response MUST be returned.
2番目の引数がメッセージIDであり、そのような物品が存在しない場合、430応答が返されなければなりません。 2番目の引数が範囲であるか、または省略され、現在選択されているニュースグループが無効である場合、412応答が返されなければなりません。 2番目の引数が二番目の数字は、最初の1未満である場合を含めて、現在選択されているニュースグループの範囲とその数の範囲内でない記事が存在している場合、423応答が返されなければなりません。第二引数が省略され、現在の資料番号が無効となる場合は、420応答が返されなければなりません。
A server MAY only allow HDR commands for a limited set of fields; it may behave differently in this respect for the first (message-id) form from how it would for the other forms. If so, it MUST respond with the generic 503 response to attempts to request other fields, rather than return erroneous results, such as a successful empty response.
サーバーは、フィールドのみの限定セットのためのHDRコマンドを可能にすることができます。それがどのように他の形態の場合とから第（メッセージID）形式のために、この点において異なる挙動をすることができます。もしそうなら、それは、このような成功した空の応答として誤った結果を、他のフィールドを要求するのではなく、返却しようとする試みに、一般的な503応答で応じなければなりません。
If HDR uses the overview database and it is inconsistent for the requested field, the server MAY return what results it can, or it MAY respond with the generic 503 response. In the latter case, the field MUST NOT appear in the output from LIST HEADERS.
HDRは概要データベースを使用していますし、それが要求されたフィールドの不整合がある場合、サーバはそれができるの結果何を返す事ができる、またはそれは、一般的な503応答で応答することができます。後者の場合、フィールドは、LISTヘッダーからの出力に現れてはいけません。
Example of a successful retrieval of subject lines from a range of articles (3000235 has no Subject header, and 3000236 is missing):
記事の範囲から件名の成功した検索の例（3000235には件名ヘッダを持っていない、及び3000236が欠落しています）。
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR Subject 3000234-3000238 [S] 225 Headers follow [S] 3000234 I am just a test article [S] 3000235 [S] 3000237 Re: I am just a test article [S] 3000238 Ditto [S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR件名3000234から3000238 [S] 225のヘッダが続く[S] 3000234私はちょうどテスト記事[S] 3000235 [S] 3000237再：私はちょうどテスト記事[S] 3000238同上[S]です。
Example of a successful retrieval of line counts from a range of articles:
ラインの成功した検索の例は、記事の範囲からカウントします。
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR :lines 3000234-3000238 [S] 225 Headers follow [S] 3000234 42 [S] 3000235 5 [S] 3000237 11 [S] 3000238 2378 [S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR：線3000234-3000238【のS] 225のヘッダが続く[S] 3000234 42 [S] 3000235 5 [S] 3000237 11 [S] 3000238 2378 [S]。
Example of a successful retrieval of the subject line from an article by message-id:
メッセージIDによって物品から件名の成功した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR subject <i.am.a.test.article@example.com> [S] 225 Header information follows [S] 0 I am just a test article [S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR被験者<i.am.a.test.article@example.com> [S] 225ヘッダ情報は、以下の[S] 0私はちょうどテスト記事[S]。
Example of a successful retrieval of the subject line from the current article:
現在の記事から件名の成功した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR subject [S] 225 Header information follows [S] 3000234 I am just a test article [S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR対象[S] 225ヘッダ情報は、[S] 3000234私はちょうど試験物品[S]を以下。
Example of an unsuccessful retrieval of a header from an article by message-id:
メッセージIDによって物品からヘッダの失敗検索の例：
[C] HDR subject <i.am.not.there@example.com> [S] 430 No Such Article Found
[C] HDR主題<i.am.not.there@example.com> [S] 430が見つかりませんこのような条
Example of an unsuccessful retrieval of headers from articles by number because no newsgroup was selected first:
数によって物品からヘッダの失敗検索の例ないニュースグループが最初に選択されなかったため。
[Assumes currently selected newsgroup is invalid.] [C] HDR subject 300256- [S] 412 No newsgroup selected
[現在選択されているニュースグループが無効であると仮定。] [C] HDR対象300256- [S] 412なしニュースグループ選択
Example of an unsuccessful retrieval of headers because the currently selected newsgroup is empty:
ヘッダーの失敗検索の例では、現在選択されたニュースグループが空であるため。
[C] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] HDR subject 1- [S] 423 No articles in that range
[C]グループexample.empty.newsgroup [S] 211 0 0 example.empty.newsgroup [C] HDR対象1- [S] 423という範囲ではありません記事
Example of an unsuccessful retrieval of headers because the server does not allow HDR commands for that header:
サーバーはそのヘッダーのHDRコマンドを許可しないため、ヘッダの失敗した検索の例：
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR Content-Type 3000234-3000238 [S] 503 HDR not permitted on Content-Type
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDRのContent-Type 3000234-3000238 [S] HDRは、コンテンツタイプに許可されていない503
Indicating capability: HDR
示す機能：HDR
Syntax LIST HEADERS [MSGID|RANGE]
構文LIST HEADERS [MSGID | RANGE]
Responses 215 Field list follows (multi-line)
215フィールドのリストは以下の応答（マルチライン）
Parameters MSGID Requests list for access by message-id RANGE Requests list for access by range
パラメータMSGIDは範囲がアクセスするためのメッセージID範囲要求リストによるアクセスのためのリストを要求します
See Section 7.6.1 for general requirements of the LIST command.
LISTコマンドの一般的な要件については、セクション7.6.1を参照してください。
The LIST HEADERS command returns a list of fields that may be retrieved using the HDR command.
LISTヘッダーコマンドは、HDRコマンドを使用して取得することができるフィールドのリストを返します。
The information is returned as a multi-line data block following the 215 response code and contains one line for each field name (excluding the trailing colon for headers and including the leading colon for metadata items). If the implementation allows any header to be retrieved, it MUST NOT include any header names in the list but MUST include the special entry ":" (a single colon on its own). It MUST still explicitly list any metadata items that are available. The order of items in the list is not significant; the server need not even consistently return the same order. The list MAY be empty (though in this circumstance there is little point in providing the HDR command).
情報は、215応答コード次のマルチラインのデータブロックとして戻され、各フィールド名（ヘッダーの末尾にコロンを除くメタデータ項目のための主要な結腸を含む）のための1つの行が含まれています。実装は任意のヘッダを取得することを可能にする場合は、リスト内の任意のヘッダ名を含んではいけませんが、特別なエントリ含まなければならない「：」（独自にシングルコロン）。それはまだ明示的に使用可能な任意のメタデータ項目をリストする必要があります。リスト内の項目の順序は重要ではありません。サーバーでも一貫して同じ順序を返す必要はありません。 （この状況でHDRコマンドを提供するにはほとんどのポイントがあるが）リストが空であってもよいです。
An implementation that also supports the OVER command SHOULD at least permit all the headers and metadata items listed in the output from the LIST OVERVIEW.FMT command.
また、OVERコマンドをサポートする実装は、少なくともLISTのOVERVIEW.FMTコマンドの出力にリストされているすべてのヘッダーおよびメタデータ項目を可能にすべきです。
If the server treats the first form of the HDR command (message-id specified) differently from the other two forms (range specified or current article number used) in respect of which headers or metadata items are available, then the following apply:
利用可能であるサーバーはHDRコマンドの最初の形式を扱う場合（メッセージIDが指定された）異なる他の二つの形式（使用する範囲指定または現在の文書番号）からヘッダまたはメタデータ項目に関して、以下が適用されます。
o If the MSGID argument is specified, the results MUST be those available for the first form of the HDR command.
MSGID引数が指定されている場合は、O、結果はHDRコマンドの最初の形式のために利用可能なものでなければなりません。
o If the RANGE argument is specified, the results MUST be those available for the second and third forms of the HDR command.
RANGE引数が指定されている場合、O、結果はHDRコマンドの第二及び第三の形態で使用可能なものでなければなりません。
o If no argument is specified, the results MUST be those available in all forms of the HDR command (that is, it MUST only list those items listed in both the previous cases).
引数が指定されていない場合は、O、結果はHDRコマンドのすべての形式で使用可能な（つまり、それだけで、両方の前の例に記載された項目の一覧を表示しなければならない）でなければなりません。
If the server does not treat the various forms differently, then it MUST ignore any argument and always produce the same results (though not necessarily always in the same order).
サーバーを異なる様々な形態を治療していない場合、それは任意の引数を無視しなければならないし、常に（必ずしも常に同じ順序でも）同じ結果を生成します。
If the HDR command is not implemented, the meaning of the output from this command is not specified, but it must still meet the above syntactic requirements.
HDRコマンドが実装されていない場合は、このコマンドの出力の意味が指定されていないが、それはまだ上記の構文上の要件を満たす必要があります。
Example of an implementation providing access to only a few headers:
ほんの数ヘッダーへのアクセスを提供する実装の例：
[C] LIST HEADERS [S] 215 headers supported: [S] Subject [S] Message-ID [S] Xref [S] .
[C] LISTヘッダー[S] 215のヘッダサポート：[S]テーマ[S]のMessage-ID [S]外部参照[S]。
Example of an implementation providing access to the same fields as the first example in Section 8.4.3:
セクション8.4.3の最初の例と同じフィールドへのアクセスを提供する実装の例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] OVER [S] HDR [S] LIST ACTIVE NEWSGROUPS HEADERS OVERVIEW.FMT [S] . [C] LIST HEADERS [S] 215 headers and metadata items supported: [S] Date [S] Distribution [S] From [S] Message-ID [S] References [S] Subject [S] Xref [S] :bytes [S] :lines [S] .
[C] CAPABILITIES [S] 101の能力リスト：[S] HDR [S] LIST ACTIVE NEWSGROUPS HEADERS OVERVIEW.FMT [S] OVER [S] VERSION 2 [S] READER [S]。 [C] LISTヘッダー[S] 215のヘッダとメタデータサポート：[S]のMessage-ID [S]参考文献[S]被験者から[S]日付[S]分布[S]を[S]外部参照[S]：バイト[S]：線[S]。
Example of an implementation providing access to all headers:
すべてのヘッダへのアクセスを提供する実装の例：
[C] LIST HEADERS [S] 215 metadata items supported: [S] : [S] :lines [S] :bytes [S] :x-article-number [S] .
[C] LISTヘッダー[S] 215のメタデータサポート：[S] [S]：線[S]：バイト[S]：X-資料番号[S]。
Example of an implementation distinguishing the first form of the HDR command from the other two forms:
他の二つの形式からHDRコマンドの最初の形式を区別実装例：
[C] LIST HEADERS RANGE [S] 215 metadata items supported: [S] : [S] :lines [S] :bytes [S] . [C] LIST HEADERS MSGID [S] 215 headers and metadata items supported: [S] Date [S] Distribution [S] From [S] Message-ID [S] References [S] Subject [S] :lines [S] :bytes [S] :x-article-number [S] . [C] LIST HEADERS [S] 215 headers and metadata items supported: [S] Date [S] Distribution [S] From [S] Message-ID [S] References [S] Subject [S] :lines [S] :bytes [S] .
[C] LISTヘッダ範囲[S]サポート215個のメタデータ項目：[S] [S]：線[S]：バイト[S]。 [C] LIST HEADERS MSGID [S] 215のヘッダとメタデータサポート：[S]のMessage-ID [S]参考文献[S]被験者から[S]日付[S]分布[S]を[S]：線[S] ：バイト[S]：X-資料番号[S]。 [C] LISTヘッダー[S]サポート215のヘッダとメタデータ：[S]日付[S]から配信[S] [S]のMessage-ID [S]参考文献[S]テーマ[S]：線[S]：バイト[S]。
Note that :x-article-number does not appear in the last set of output.
なお：X-記事数は、出力の最後のセットには表示されません。
Each of the following sections describes the syntax of a major element of NNTP. This syntax extends and refines the descriptions elsewhere in this specification and should be given precedence when resolving apparent conflicts. Note that ABNF [RFC4234] strings are case insensitive. Non-terminals used in several places are defined in a separate section at the end.
次の各セクションには、NNTPの主要な要素の構文について説明します。この構文は拡張し、本明細書の別の箇所の記述を洗練して見かけの競合を解決する際の優先順位を与えられるべきです。 ABNF [RFC4234]の文字列は大文字小文字を区別しないことに注意してください。いくつかの場所で使用される非端子が端部で別々のセクションで定義されています。
Between them, the non-terminals <command-line>, <command-datastream>, <command-continuation>, and <response> specify the text that flows between client and server. A consistent naming scheme is used in this document for the non-terminals relating to each command, and SHOULD be used by the specification of registered extensions.
それらの間に、非端末<コマンドライン>、<コマンドデータストリーム>、<コマンド継続>、および<応答>クライアントとサーバの間を流れるテキストを指定します。一貫した命名方式は、各コマンドに関連した非端末は、この文書で使用され、そして登録拡張の仕様で使用されるべきです。
For each command, the sequence is as follows:
次のようにコマンドごとに、シーケンスは次のとおりです。
o The client sends an instance of <command-line>; the syntax for the EXAMPLE command is <example-command>.
Oクライアントは、<コマンドライン>のインスタンスを送信します。例コマンドの構文は、<例-コマンド>です。
o If the client is one that immediately streams data, it sends an instance of <command-datastream>; the syntax for the EXAMPLE command is <example-datastream>.
クライアントはすぐにデータをストリーム1である場合には、O、それは<コマンドデータストリーム>のインスタンスを送信します。例コマンドの構文は、<例-データストリーム>です。
o The server sends an instance of <response>.
Oサーバは<応答>のインスタンスを送信します。
* The initial response line is independent of the command that generated it; if the 000 response has arguments, the syntax of the initial line is <response-000-content>.
*初期応答ラインは、それを生成したコマンドとは無関係です。 000応答は、引数を持っている場合、最初の行の構文は、<応答-000-コンテンツ>です。
* If the response is multi-line, the initial line is followed by a <multi-line-data-block>. The syntax for the contents of this block after "dot-stuffing" has been removed is (for the 000 response to the EXAMPLE command) <example-000-ml-content> and is an instance of <multi-line-response-content>.
応答が複数行である場合*、初期ラインは、<マルチラインデータブロック>が続きます。 「ドット・スタッフィング」が除去された後に、このブロックの内容の構文は、<例-000-ML-コンテンツ>（実施例コマンドに対する000応答）であり、<マルチライン応答コンテンツのインスタンスであります>。
o While the latest response is one that indicates more data is required (in general, a 3xx response):
最新の応答がより多くのデータを（一般的には、3xx応答）が必要であることを示しものである一方で、O：
* the client sends an instance of <command-continuation>; the syntax for the EXAMPLE continuation following a 333 response is <example-333-continuation>;
*クライアントは、<コマンド継続>のインスタンスを送信します。 333レスポンス次の例継続の構文は、<例-333-継続>です。
* the server sends another instance of <response>, as above.
*サーバは、上記のように、<応答>の別のインスタンスを送信します。
(There are no commands in this specification that immediately stream data, but this non-terminal is defined for the convenience of extensions.)
（そこすぐにデータをストリーミングするこの仕様にはコマンドはありませんが、この非端子は拡張の利便性のために定義されています。）
This syntax defines the non-terminal <command-line>, which represents what is sent from the client to the server (see section 3.1 for limits on lengths).
この構文は、非端末<コマンドライン>を定義し、（長さに制限するためのセクション3.1を参照）クライアントからサーバに送信されるものを表します。
command-line = command EOL command = X-command X-command = keyword *(WS token)
コマンドライン=コマンドEOLコマンド= X-コマンドX-コマンド=キーワード*（WSトークン）
command =/ article-command / body-command / capabilities-command / date-command / group-command / hdr-command / head-command / help-command / ihave-command / last-command / list-command / listgroup-command / mode-reader-command / newgroups-command / newnews-command / next-command / over-command / post-command / quit-command / stat-command
コマンド= /記事-コマンド/ボディ・コマンド/機能コマンド/日-コマンド/グループコマンド/ HDR-コマンド/ヘッド-コマンド/ヘルプコマンド/ IHAVEコマンド/最後のコマンド/リスト・コマンド/ listgroupコマンド/モードリーダコマンド/ NEWGROUPSコマンド/ NEWNEWSコマンド/ NEXTコマンド/オーバーコマンド/ポストコマンド/終了コマンド/ STATコマンド
article-command = "ARTICLE" [WS article-ref] body-command = "BODY" [WS article-ref] capabilities-command = "CAPABILITIES" [WS keyword] date-command = "DATE" group-command = "GROUP" [WS newsgroup-name] hdr-command = "HDR" WS header-meta-name [WS range-ref] head-command = "HEAD" [WS article-ref] help-command = "HELP" ihave-command = "IHAVE" WS message-id last-command = "LAST" list-command = "LIST" [WS list-arguments] listgroup-command = "LISTGROUP" [WS newsgroup-name [WS range]] mode-reader-command = "MODE" WS "READER" newgroups-command = "NEWGROUPS" WS date-time newnews-command = "NEWNEWS" WS wildmat WS date-time next-command = "NEXT" over-command = "OVER" [WS range-ref] post-command = "POST" quit-command = "QUIT" stat-command = "STAT" [WS article-ref]
記事-コマンド= "ARTICLE" [WS記事-REF]ボディ・コマンド= "BODY" [WSの記事-REF]機能-コマンド= "機能" [WSキーワード]日付コマンド= "DATE" グループ・コマンド=「GROUP 「[WSニュースグループ名] = HDRコマンド "HDR" WSヘッダメタ名[WS範囲-REF]ヘッドコマンド= "HEAD" [WS物品-REF]ヘルプコマンド= "HELP" IHAVEコマンド= "IHAVE" WSのメッセージIDの最後のコマンド= "LAST" リスト・コマンド= "LIST" [WSリスト-引数] listgroupコマンド= "LISTGROUP" モードリーダーコマンド[WSニュースグループ名[WS]は範囲] = "MODE" WS "READER" NEWGROUPSコマンド= "NEWGROUPS" WS日時NEWNEWSコマンド= "NEWNEWS" WS WILDMAT WS日時次のコマンドは= "NEXT" オーバーコマンド= "OVER" [WS範囲-REF ]ポストコマンド= "POST" 終了コマンドを= "QUIT" STAT-コマンド= "STAT" [WSの記事-REF]
article-ref = article-number / message-id date = date2y / date4y date4y = 4DIGIT 2DIGIT 2DIGIT date2y = 2DIGIT 2DIGIT 2DIGIT date-time = date WS time [WS "GMT"] header-meta-name = header-name / metadata-name list-arguments = keyword [WS token] metadata-name = ":" 1*A-NOTCOLON range = article-number ["-" [article-number]] range-ref = range / message-id time = 2DIGIT 2DIGIT 2DIGIT
物品-REF =物品数/メッセージID日付= date2y / date4y date4y = 4桁2DIGIT 2DIGIT date2y = 2DIGIT 2DIGIT 2DIGIT日時=日付WS時間[WS "GMT"]ヘッダメタ名=ヘッダ名/メタデータ-nameリスト引数=キーワード[WSトークン]メタデータ名= "：" 1 * A-NOTCOLON範囲=記事番号[ " - " [資料番号]]の範囲-REF =範囲/メッセージID時間= 2DIGIT 2DIGIT 2DIGIT
This syntax defines the further material sent by the client in the case of multi-stage commands and those that stream data.
この構文は、多段コマンドおよびデータをストリーミングするものの場合には、クライアントによって送信されるさらなる材料を規定します。
command-datastream = UNDEFINED ; not used, provided as a hook for extensions command-continuation = ihave-335-continuation / post-340-continuation
コマンド・データストリーム= UNDEFINED。拡張コマンド継続= IHAVE-335-継続/ポスト340は継続のためのフックとして設けられ、使用されていません
ihave-335-continuation = encoded-article post-340-continuation = encoded-article
IHAVE-335-継続=エンコードさ-物品ポスト340-継続=エンコードされ、物品
encoded-article = multi-line-data-block ; after undoing the "dot-stuffing", this MUST match <article>
符号化された、物品=マルチラインデータ・ブロック; 「ドットスタッフィング」を元に戻した後、これが一致しなければならない<記事>
This syntax defines the non-terminal <response>, which represents the generic form of responses; that is, what is sent from the server to the client in response to a <command> or a <command-continuation>.
この構文は、応答の一般的な形を表す非終端<応答>を、定義します。それは、<コマンド>または<コマンド継続>に応じて、サーバからクライアントに送信されているもの、です。
response = simple-response / multi-line-response simple-response = initial-response-line multi-line-response = initial-response-line multi-line-data-block
応答=単純応答/マルチライン応答単純応答=初期応答ラインマルチライン応答=初期応答ラインマルチラインデータブロック
initial-response-line = initial-response-content [SP trailing-comment] CRLF initial-response-content = X-initial-response-content X-initial-response-content = 3DIGIT *(SP response-argument) response-argument = 1*A-CHAR trailing-comment = *U-CHAR
初期の応答ライン=最初の応答内容〔SPトレーリングコメント] CRLF初期応答含量= X-初期応答コンテンツX-初期応答含量= 3DIGIT *（SP応答引数）応答引数= 1 * A-CHAR末尾-コメント= * U-CHAR
This syntax defines the specific initial response lines for the various commands in this specification (see section 3.1 for limits on lengths). Only those response codes with arguments are listed.
この構文は、（長さに制限するためのセクション3.1を参照されたい）、本明細書中の種々のコマンドのための特定の初期応答線を画定します。引数付きのもののみ応答コードが記載されています。
initial-response-content =/ response-111-content / response-211-content / response-220-content / response-221-content / response-222-content / response-223-content / response-401-content
初期応答含量= /応答111コンテンツ/応答211コンテンツ/応答220コンテンツ/応答221コンテンツ/応答222コンテンツ/応答223コンテンツ/応答401コンテンツ
response-111-content = "111" SP date4y time response-211-content = "211" 3(SP article-number) SP newsgroup-name response-220-content = "220" SP article-number SP message-id response-221-content = "221" SP article-number SP message-id response-222-content = "222" SP article-number SP message-id response-223-content = "223" SP article-number SP message-id response-401-content = "401" SP capability-label
応答111コンテンツ= "111" SPのdate4y時間応答-211-コンテンツ= "211" 3（SP物品数）SPニュースグループ名の応答-220-コンテンツ= "220" SP資料番号SPのメッセージID応答-221-内容は= "221" SP資料番号SPメッセージID応答-222含有量は= "222" SP資料番号SPメッセージID応答223コンテンツ= "223" SP資料番号SPのメッセージID応答-401-コンテンツ= "401" SP機能、ラベル
This syntax defines the content of the various multi-line responses; more precisely, it defines the part of the response in the multi-line data block after any "dot-stuffing" has been undone. The numeric portion of each non-terminal name indicates the response code that is followed by this data.
この構文は、様々なマルチライン応答の内容を定義します。任意の「ドットスタッフィング」が取り消された後に、より正確には、複数行のデータブロックに応答の一部を画定します。各非端末名の数字部分は、このデータに続いて応答コードを示しています。
multi-line-response-content = article-220-ml-content / body-222-ml-content / capabilities-101-ml-content / hdr-225-ml-content / head-221-ml-content / help-100-ml-content / list-215-ml-content / listgroup-211-ml-content / newgroups-231-ml-content / newnews-230-ml-content / over-224-ml-content
マルチライン応答コンテンツ=物品220-ML-コンテンツ/ボディ-222-ML-コンテンツ/機能-101-ML-コンテンツ/ HDR-225-ML-コンテンツ/ヘッド221-ML-コンテンツ/ヘルプ - 100mlのコンテンツ/リスト215-ML-コンテンツ/ listgroup-211-ML-コンテンツ/ NEWGROUPS-231-ML-コンテンツ/ NEWNEWS-230-ML-コンテンツ/オーバー-224-ML-コンテンツ
article-220-ml-content = article body-222-ml-content = body capabilities-101-ml-content = version-line CRLF
物品220-ML-コンテンツ=物品本体-222-ML-コンテンツ=身体機能-101-ML-含量=バージョンラインCRLF
*(capability-line CRLF) hdr-225-ml-content = *(article-number SP hdr-content CRLF) head-221-ml-content = 1*header help-100-ml-content = *(*U-CHAR CRLF) list-215-ml-content = list-content listgroup-211-ml-content = *(article-number CRLF) newgroups-231-ml-content = active-groups-list newnews-230-ml-content = *(message-id CRLF) over-224-ml-content = *(article-number over-content CRLF)
*（能力ラインCRLF）HDR-225-ML-含量= *（資料番号SP HDRコンテンツCRLF）ヘッド-221-ML-含量= 1 *ヘッダヘルプ-100-ML-含量= *（* U- CHAR CRLF）リスト215-ML-含量=リストコンテンツlistgroup-211-ML-含量= *（物品番号CRLF）NEWGROUPS-231-ML-含量=アクティブグループリストNEWNEWS-230-ML-含量= *（メッセージID CRLF）上-224-ML-含量= *（物品番号オーバーコンテンツCRLF）
active-groups-list = *(newsgroup-name SPA article-number SPA article-number SPA newsgroup-status CRLF) hdr-content = *S-NONTAB hdr-n-content = [(header-name ":" / metadata-name) SP hdr-content] list-content = body newsgroup-status = %x79 / %x6E / %x6D / private-status over-content = 1*6(TAB hdr-content) / 7(TAB hdr-content) *(TAB hdr-n-content) private-status = token ; except the values in newsgroup-status
アクティブグループリスト= *（ニュースグループ名SPA資料番号SPA資料番号SPAニュースグループステータスCRLF）HDR-含量= * S-NONTAB HDR-N-含量= [（ヘッダ名 "：" / metadata-オーバーコンテンツ名）SPのHDRコンテンツ]リスト内容=本体ニュースグループステータス=％X79 /％x6E /％x6dは/プライベートステータス= 1 * 6（TABのHDR-含量）/ 7（TABのHDRコンテンツ）* （TAB HDR-N-コンテンツ）プライベートステータス=トークン。ニュースグループ・ステータスにある値を除きます
This syntax defines the generic form of a capability line in the capabilities list (see Section 3.3.1).
この構文は、機能リストの機能ラインの一般的な形式を定義します（セクション3.3.1を参照してください）。
capability-line = capability-entry capability-entry = X-capability-entry X-capability-entry = capability-label *(WS capability-argument) capability-label = keyword capability-argument = token
機能ライン=機能-入力機能-エントリ= X-機能-エントリX-機能-エントリ=機能ラベル*（WS機能引数）機能、ラベル=キーワード能力の引数=トークン
This syntax defines the specific capability entries for the capabilities in this specification.
この構文は、この仕様で機能するための特定の機能項目を定義します。
capability-entry =/ hdr-capability / ihave-capability / implementation-capability / list-capability / mode-reader-capability / newnews-capability / over-capability / post-capability / reader-capability
能力エントリ= / HDR-能力/ IHAVE-能力/実装能力/リスト能力/モードリーダ能力/ NEWNEWS-能力/オーバー能力/ポスト能力/リーダ能力
hdr-capability = "HDR" ihave-capability = "IHAVE" implementation-capability = "IMPLEMENTATION" *(WS token) list-capability = "LIST" 1*(WS keyword) mode-reader-capability = "MODE-READER" newnews-capability = "NEWNEWS" over-capability = "OVER" [WS "MSGID"] post-capability = "POST" reader-capability = "READER"
HDR-機能= "HDR" IHAVE-機能= "IHAVE" 実装機能= "実装" *（WSトークン）リスト機能= "LIST" 1 *（WSキーワード）モードリーダ機能= "MODE-READER" NEWNEWS-能力= "NEWNEWS" 過剰能力= "OVER" [WSする "＃"]ポスト能力= "POST" リーダ能力= "READER"
version-line = "VERSION" 1*(WS version-number) version-number = nzDIGIT *5DIGIT
バージョンライン=「バージョン」1 *（WSバージョン番号）バージョン番号= nzDIGIT * 5DIGIT
This section defines more specifically the keywords for the LIST command and the syntax of the corresponding response contents.
このセクションでは、LISTコマンド及び対応する応答コンテンツの構文について、より具体的なキーワードを定義します。
; active list-arguments =/ "ACTIVE" [WS wildmat] list-content =/ list-active-content list-active-content = active-groups-list
;アクティブリスト引数= /「ACTIVE」[WS WILDMAT]リスト内容= /リストアクティブコンテンツリストアクティブコンテンツ=アクティブグループリスト
; active.times list-arguments =/ "ACTIVE.TIMES" [WS wildmat] list-content =/ list-active-times-content list-active-times-content = *(newsgroup-name SPA 1*DIGIT SPA newsgroup-creator CRLF) newsgroup-creator = U-TEXT
; active.timesリスト引数= / "ACTIVE.TIMES" [WSのWILDMAT]リスト内容= /リスト-アクティブ倍コンテンツリスト-アクティブ倍-コンテンツ= *（ニュースグループ名SPA 1 * DIGIT SPAのニュースグループ、作成者CRLF）ニュースグループ・クリエーター= U-TEXT
; distrib.pats list-arguments =/ "DISTRIB.PATS" list-content =/ list-distrib-pats-content list-distrib-pats-content = *(1*DIGIT ":" wildmat ":" distribution CRLF) distribution = token
; distrib.patsリスト引数= / "DISTRIB.PATS" リスト内容= /リストDISTRIB-PATSコンテンツリストDISTRIB-PATS-含量= *（1 * DIGIT "：" WILDMAT "：" 分布CRLF）分布=トークン
; headers list-arguments =/ "HEADERS" [WS ("MSGID" / "RANGE")] list-content =/ list-headers-content list-headers-content = *(header-meta-name CRLF) / *((metadata-name / ":") CRLF)
;ヘッダリスト引数= / "HEADERS" [WS（ "MSGID" / "RANGE"）]リスト内容= /リスト・ヘッダ・コンテンツリストヘッダコンテンツ= *（ヘッダメタ名CRLF）/ *（（メタデータ名/ "："）CRLF）
; newsgroups list-arguments =/ "NEWSGROUPS" [WS wildmat] list-content =/ list-newsgroups-content list-newsgroups-content =
;ニュースグループリストの引数= /「NEWSGROUPS」[WSのWILDMAT]リスト内容= /リスト・ニュースグループコンテンツリスト・ニュースグループ・コンテンツ=
*(newsgroup-name WS newsgroup-description CRLF) newsgroup-description = S-TEXT
*（ニュースグループ名WSニュースグループ記述CRLF）ニュースグループ記述= S-TEXT
; overview.fmt list-arguments =/ "OVERVIEW.FMT" list-content =/ list-overview-fmt-content list-overview-fmt-content = "Subject:" CRLF "From:" CRLF "Date:" CRLF "Message-ID:" CRLF "References:" CRLF ( ":bytes" CRLF ":lines" / "Bytes:" CRLF "Lines:") CRLF *((header-name ":full" / metadata-name) CRLF)
; "From：" CRLF CRLF "日：" CRLF「メッセージ：overview.fmtリスト-引数= / "OVERVIEW.FMT" リスト・コンテンツ= /リスト-概要-fmtをコンテンツリスト-概要-FMT-内容= "件名" -ID：」CRLF "参照：" CRLF（ "：バイト" CRLF "：行" / "バイト：" CRLF "行："）CRLF×（（ヘッダ名 "フル" /メタデータ名）CRLF）
This syntax defines the non-terminal <article>, which represents the format of an article as described in Section 3.6.
この構文は、セクション3.6で説明したように記事の形式を表す非終端<記事>を定義します。
article = 1*header CRLF body header = header-name ":" [CRLF] SP header-content CRLF header-content = *(S-CHAR / [CRLF] WS) body = *(*B-CHAR CRLF)
記事= 1 *ヘッダCRLFボディヘッダ=ヘッダ名 "：" [CRLF] SPヘッダコンテンツCRLFヘッダ・コンテンツ= *（S-CHAR / [CRLF] WS）本体= *（* B-CHAR CRLF）
These non-terminals are used at various places in the syntax and are collected here for convenience. A few of these non-terminals are not used in this specification but are provided for the consistency and convenience of extension authors.
これらの非端子は、構文内のさまざまな場所で使用され、便宜上ここに集めています。これらの非端末の数は、本明細書中で使用されていないが、拡張作者の一貫性と利便性のために提供されています。
multi-line-data-block = content-lines termination content-lines = *([content-text] CRLF) content-text = (".." / B-NONDOT) *B-CHAR termination = "." CRLF
マルチライン・データ・ブロック=コンテンツ線終端コンテンツ線= *（[コンテンツテキスト] CRLF）コンテンツテキスト=（ ".." / B-NONDOT）* B-CHAR終端= "" CRLF
article-number = 1*16DIGIT header-name = 1*A-NOTCOLON keyword = ALPHA 2*(ALPHA / DIGIT / "." / "-") message-id = "<" 1*248A-NOTGT ">" newsgroup-name = 1*wildmat-exact token = 1*P-CHAR
記事番号= 1 * A-NOTCOLONキーワード= 1 * 16DIGITヘッダ名= ALPHA 2 *（ALPHA / DIGIT / / "" " - "）、メッセージID = "<" 1 * 248A-NOTGT ">" ニュースグループ-name = 1 * WILDMAT、正確なトークン= 1 * P-CHAR
wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) wildmat-pattern = 1*wildmat-item wildmat-item = wildmat-exact / wildmat-wild wildmat-exact = %x22-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E /
WILDMAT = WILDMATパターン*（ "" [ "！"] WILDMATパターン）WILDMATパターン= 1 * WILDMAT項目WILDMAT項目= WILDMAT-厳密/ WILDMAT野生WILDMAT-正確=％x22-29 /％X2B /％x2D-3E /％x40-5A /％x5E-7E /
UTF8-non-ascii ; exclude ! * , ? [ \ ] wildmat-wild = "*" / "?"
UTF8-非ASCII;除外！ *、？ [\] WILDMAT-野生= "*" / "？"
base64 = *(4base64-char) [base64-terminal] base64-char = UPPER / LOWER / DIGIT / "+" / "/" base64-terminal = 2base64-char "==" / 3base64-char "="
BASE64 = *（4base64-CHAR）BASE64末端] base64でCHAR = UPPER / LOWER / DIGIT / "+" / "/" BASE64末端= 2base64-CHAR "==" / 3base64-CHAR "="
; Assorted special character sets ; A- means based on US-ASCII, excluding controls and SP ; P- means based on UTF-8, excluding controls and SP ; U- means based on UTF-8, excluding NUL CR and LF ; B- means based on bytes, excluding NUL CR and LF A-CHAR = %x21-7E A-NOTCOLON = %x21-39 / %x3B-7E ; exclude ":" A-NOTGT = %x21-3D / %x3F-7E ; exclude ">" P-CHAR = A-CHAR / UTF8-non-ascii U-CHAR = CTRL / TAB / SP / A-CHAR / UTF8-non-ascii U-NONTAB = CTRL / SP / A-CHAR / UTF8-non-ascii U-TEXT = P-CHAR *U-CHAR B-CHAR = CTRL / TAB / SP / %x21-FF B-NONDOT = CTRL / TAB / SP / %x21-2D / %x2F-FF ; exclude "."
;盛り合わせの特殊文字セット。コントロールとSPを除くUS-ASCIIに基づいA-手段;コントロールとSPを除くUTF-8に基づいてP-手段; UTF-8、NUL CRとLFを除く基づいてU-手段; NUL CRとLF A-CHAR =％x21-7E A-NOTCOLON =％x21-39 /％X3B-7E除くバイトに基づいてB-手段;除外 "：" A-NOTGT =％x21-3D /％からx3F-7E;除外 ">" P-CHAR = A-CHAR / UTF8-ASCII以外のU-CHAR = CTRL / TAB / SP / A-CHAR / UTF8-ASCII以外のU-NONTAB = CTRL / SP / A-CHAR / UTF8-非ASCII U-TEXT = P-CHAR * U-CHAR B-CHAR = CTRL / TAB / SP /％X21-FF B-NONDOT = CTRL / TAB / SP /％x21-2D /％x2F-FF。除外「」
ALPHA = UPPER / LOWER ; use only when case-insensitive CR = %x0D CRLF = CR LF CTRL = %x01-08 / %x0B-0C / %x0E-1F DIGIT = %x30-39 nzDIGIT = %x31-39 EOL = *(SP / TAB) CRLF LF = %x0A LOWER = %x61-7A SP = %x20 SPA = 1*SP TAB = %x09 UPPER = %x41-5A UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 = %xC2-DF UTF8-tail UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2UTF8-tail / %xED %x80-9F UTF8-tail / %xEE-EF 2UTF8-tail UTF8-4 = %xF0 %x90-BF 2UTF8-tail / %xF1-F3 3UTF8-tail / %xF4 %x80-8F 2UTF8-tail UTF8-tail = %x80-BF WS = 1*(SP / TAB)
ALPHA = UPPER / LOWER。使用のみ大文字と小文字を区別しないCR =％x0D CRLF = CR LF CTRL =％x01-08 /％X0B-0C /％のx0E-1F DIGIT =％x30-39 nzDIGIT =％x31-39 EOL = *（SP / TAB） CRLF LF =％X0A LOWER =％x61-7A SP =％X20 SPA = 1 * SP TAB =％のx09のUPPER =％x41-5A UTF8-非ASCII = UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 =％XC2-DF UTF8-尾UTF8-3 =％xE0％XA0-BFのUTF8テール/％XE1-EC 2UTF8テール/％XED％x80-9F UTF8テール/％XEE-EF 2UTF8テールUTF8-4 =％XF0％X90-BF 2UTF8テール/％XF1-F3 3UTF8テール/％XF4％x80-8F 2UTF8テールUTF8-尾=％X80-BF WS = 1 *（SP / TAB）
The following non-terminals require special consideration. They represent situations where material SHOULD be restricted to UTF-8, but implementations MUST be able to cope with other character encodings. Therefore, there are two sets of definitions for them.
以下の非端末は、特別な配慮が必要です。彼らは、材料がUTF-8に制限されるべき状況を表しているが、実装は、他の文字エンコーディングに対処できなければなりません。そのため、それらの定義の2セットがあります。
Implementations MUST accept any content that meets this syntax:
実装は、この構文を満たす任意のコンテンツを受け入れなければなりません：
S-CHAR = %x21-FF S-NONTAB = CTRL / SP / S-CHAR S-TEXT = (CTRL / S-CHAR) *B-CHAR
S-CHAR =％X21-FF S-NONTAB = CTRL / SP / S-CHAR S-TEXT =（CTRL / S-CHAR）* B-CHAR
and MAY pass such content on unaltered.
そして、変更されていない上、そのようなコンテンツを渡すことができます。
When generating new content or re-encoding existing content, implementations SHOULD conform to this syntax:
新しいコンテンツや再エンコードする既存のコンテンツを生成する場合、実装は、この構文に準拠している必要があります：
S-CHAR = P-CHAR S-NONTAB = U-NONTAB S-TEXT = U-TEXT
S-CHAR = P-CHAR S-NONTAB = U-NONTAB S-TEXT = U-TEXT
The specification of a registered extension MUST include formal syntax that defines additional forms for the following non-terminals:
登録拡張の仕様は、以下の非端末のための追加の形態を定義する正式な構文を含める必要があります。
command for each new command other than a variant of the LIST command - the syntax of each command MUST be compatible with the definition of <X-command>;
LISTコマンドのバリアント以外のそれぞれの新しいコマンドのコマンド - 各コマンドの構文は、<X-コマンド>の定義と互換性がなければなりません。
command-datastream for each new command that immediately streams data;
すぐにデータをストリーミングし、それぞれの新しいコマンドのコマンドデータストリーム。
command-continuation for each new command that sends further material after the initial command line - the syntax of each continuation MUST be exactly what is sent to the server, including any escape mechanisms such as "dot-stuffing";
初期コマンド行の後にさらなる材料を送り、それぞれの新しいコマンドのコマンド継続 - 各継続の構文は、このような「ドットスタッフィング」などの任意のエスケープ・メカニズムを含め、サーバに送信されるかを正確にする必要があります。
initial-response-content for each new response code that has arguments - the syntax of each response MUST be compatible with the definition of <X-initial-response-content>;
引数はそれぞれの新しい応答コードに対する初期応答コンテンツ - 各応答の構文は、<X-初期応答コンテンツ>の定義と互換性がなければなりません。
multi-line-response-content for each new response code that has a multi-line response - the syntax MUST show the response after the lines containing the response code and the terminating octet have been removed and any "dot-stuffing" undone;
マルチライン応答を有する各新しい応答コードのためのマルチライン応答コンテンツ - 構文は、応答コードと終端オクテットを含む行が除去された後に応答し、任意の「ドット・スタッフィング」取り消しを示さなければなりません。
capability-entry for each new capability label - the syntax of each entry MUST be compatible with the definition of <X-capability-entry>;
それぞれの新しい機能ラベルのための能力-エントリ - 各エントリの構文は、<X-機能-エントリ>の定義と互換性がなければなりません。
list-arguments for each new variant of the LIST command - the syntax of each entry MUST be compatible with the definition of <X-command>;
LISTコマンドのそれぞれの新しいバリアントのリスト引数 - 各エントリの構文は、<X-コマンド>の定義と互換性がなければなりません。
list-content for each new variant of the LIST command - the syntax MUST show the response after the lines containing the 215 response code and the terminating octet have been removed and any "dot-stuffing" undone.
LISTコマンドのそれぞれの新しいバリアントのリスト - コンテンツ - 構文は、215応答コードと終端オクテットを含む行が削除された後で応答し、任意の「ドットスタッフィング」元に戻すを示さなければなりません。
The =/ notation of ABNF [RFC4234] and the naming conventions described in Section 9.1 SHOULD be used for this.
ABNF [RFC4234]、セクション9.1で説明した命名規則の= /表記は、このために使用されるべきです。
When the syntax in this specification, or syntax based on it, is validated, it should be noted that:
それに基づいて、この仕様では、構文、または構文が、検証された場合、それはそれを注意する必要があります。
o the non-terminals <command-line>, <command-datastream>, <command-continuation>, <response>, and <multi-line-response-content> describe basic concepts of the protocol and are not referred to by any other rule;
非端末<コマンドライン>、<コマンドデータストリーム> O、<コマンド継続>、<応答>、および<マルチライン応答コンテンツ>プロトコルの基本的な概念について説明し、任意で参照されていません他のルール;
o the non-terminal <base64> is provided for the convenience of extension authors and is not referred to by any rule in this specification;
非終端<BASE64> oを拡張作成者の便宜のために提供され、本明細書における任意のルールによって参照されていません。
o for the reasons given above, the non-terminals <S-CHAR>, <S-NONTAB>, and <S-TEXT> each have two definitions; and
O上記の理由、非端末<S-CHAR>、<S-NONTAB>、及び<S-TEXT>のためにそれぞれ2つの定義を有します。そして
o the non-terminal <UNDEFINED> is deliberately not defined.
非終端0 <UNDEFINED>故意に定義されていません。
RFC 977 [RFC977] was written at a time when internationalisation was not seen as a significant issue. As such, it was written on the assumption that all communication would be in ASCII and use only a 7-bit transport layer, although in practice just about all known implementations are 8-bit clean.
RFC 977 [RFC977]国際化が重要な問題として見られていなかった時に書かれました。このように、全ての通信はASCIIであって、実際にちょうど約すべての既知の実装は8ビットクリーンであるが、唯一の7ビットのトランスポート層を使用することを前提に書かれていました。
Since then, Usenet and NNTP have spread throughout the world. In the absence of standards for handling the issues of language and character sets, countries, newsgroup hierarchies, and individuals have found a variety of solutions that work for them but that are not necessarily appropriate elsewhere. For example, some have adopted a default 8-bit character set appropriate to their needs (such as ISO/IEC 8859-1 in Western Europe or KOI-8 in Russia), others have used ASCII (either US-ASCII or national variants) in headers but local 16-bit character sets in article bodies, and still others have gone for a combination of MIME [RFC2045] and UTF-8. With the increased use of MIME in email, it is becoming more common to find NNTP articles containing MIME headers that identify the character set of the body, but this is far from universal.
それ以来、ユーズネットやNNTPは世界中に広がっています。言語と文字セット、国、ニュースグループの階層、および個人の問題を扱うための規格が存在しない場合には彼らのために働くのさまざまなソリューションを見つけたが、それは他の場所で、必ずしも適切ではありませんしています。例えば、いくつかは（例えばロシアの西欧やKOI-8でのISO / IEC 8859-1など）自分のニーズに合った設定のデフォルト8ビット文字を採用している、他の人は、ASCII（US-ASCIIまたは国家変種のいずれか）を使用していましたヘッダが、記事本文中のローカル16ビット文字セット、および、まだ他にMIME [RFC2045]とUTF-8の組み合わせのために行っています。電子メールでのMIMEの使用の増加と、身体の文字セットを識別するMIMEヘッダを含むNNTPの記事を見つけるために、より一般的になっているが、これははるかにユニバーサルからです。
The resulting confusion does not help interoperability.
結果の混乱は、相互運用性を助けていません。
One point that has been generally accepted is that articles can contain octets with the top bit set, and NNTP is only expected to operate on 8-bit clean transport paths.
一般的に受け入れられてきた一つのポイントは、記事がトップビットが設定されたオクテットを含めることができ、およびNNTPのみ8ビットクリーン搬送経路上で動作することが期待されていることです。
Part of the role of this present specification is to eliminate this confusion and promote interoperability as far as possible. At the same time, it is necessary to accept the existence of the present situation and not break existing implementations and arrangements gratuitously, even if they are less than optimal. Therefore, the current practice described above has been taken into consideration in producing this specification.
この、本明細書の役割の一部は、この混乱を排除し、可能な限り相互運用性を促進することです。同時に、彼らが最適未満であっても、現状の存在を受け入れ、無償で既存の実装および配置を壊さないことが必要です。したがって、上述した現在の慣行は、本明細書を製造する際に考慮されています。
This specification extends NNTP from US-ASCII [ANSI1986] to UTF-8 [RFC3629]. Except in the two areas discussed below, UTF-8 (which is a superset of US-ASCII) is mandatory, and implementations MUST NOT use any other encoding.
この仕様は、US-ASCII [ANSI1986] UTF-8に[RFC3629]からNNTPを拡張します。以下に説明する二つの領域を除いて、（US-ASCIIのスーパーセットである）UTF-8が必須であり、実装は、他のエンコーディングを使用してはいけません。
Firstly, the use of MIME for article headers and bodies is strongly recommended. However, given widely divergent existing practices, an attempt to require a particular encoding and tagging standard would be premature at this time. Accordingly, this specification allows the use of arbitrary 8-bit data in articles subject to the following requirements and recommendations.
まず、記事のヘッダとボディのMIMEの使用を強くお勧めします。しかし、広く発散既存の慣行与え、特定のエンコーディングとタグ付け標準を必要とする試みは、現時点では時期尚早だろう。従って、本明細書は、次の要件と推奨事項の対象物品の任意の8ビット・データの使用を可能にします。
o The names of headers (e.g., "From" or "Subject") MUST be in US-ASCII.
ヘッダの名前（例えば、「差出人」または「件名」）Oは、US-ASCIIでなければなりません。
o Header values SHOULD use US-ASCII or an encoding based on it, such as RFC 2047 [RFC2047], until such time as another approach has been standardised. At present, 8-bit encodings (including UTF-8) SHOULD NOT be used because they are likely to cause interoperability problems.
Oヘッダの値は、別のアプローチが標準化されているような時間まで、US-ASCII又はRFC 2047 [RFC2047]として、それに基づいて符号化を使用する必要があります。彼らは相互運用性の問題を引き起こす可能性があるため、現時点では、（UTF-8を含む）の8ビットエンコーディングを使用しないでください。
o The character set of article bodies SHOULD be indicated in the article headers, and this SHOULD be done in accordance with MIME.
oを記事本文の文字セットは、記事のヘッダに示されるべきであり、これはMIMEに基づいて行われるべきです。
o Where an article is obtained from an external source, an implementation MAY pass it on and derive data from it (such as the response to the HDR command), even though the article or the data does not meet the above requirements. Implementations MUST transfer such articles and data correctly and unchanged; they MUST NOT attempt to convert or re-encode the article or derived data. (Nevertheless, a client or server MAY elect not to post or forward the article if, after further examination of the article, it deems it inappropriate to do so.)
物品は、外部ソースから得られる場合、O、インプリメンテーションは、物品又はデータは、上記の要件を満たしていなくても、（例えばHDRコマンドに対する応答として）に渡し、そこからデータを導出することができます。実装は正しくと変わらず、このような記事やデータを転送する必要があります。彼らは、物品または導出されたデータを変換するか、または再エンコードすることを試みてはいけません。 （それにもかかわらず、クライアントまたはサーバは、物品の更なる検討の後、それはそうすることが不適切と判断、場合記事を投稿したり、転送しないことを選択するかもしれません。）
This requirement affects the ARTICLE (Section 6.2.1), BODY (Section 6.2.3), HDR (Section 8.5), HEAD (Section 6.2.2), IHAVE (Section 6.3.2), OVER (Section 8.3), and POST (Section 6.3.1) commands.
この要件はARTICLE（6.2.1項）、BODY（6.2.3項）、HDR（セクション8.5）、HEAD（6.2.2項）、IHAVE（6.3.2項）、OVER（8.3節）に影響を与える、とPOST （6.3.1項）コマンド。
Secondly, the following requirements are placed on the newsgroups list returned by the LIST NEWSGROUPS command (Section 7.6.6):
第二に、以下の要件をLISTニュースグループコマンド（セクション7.6.6）によって返されたニュースグループのリストの上に配置されます。
o Although this specification allows UTF-8 for newsgroup names, they SHOULD be restricted to US-ASCII until a successor to RFC 1036 [RFC1036] standardises another approach. 8-bit encodings SHOULD NOT be used because they are likely to cause interoperability problems.
RFC 1036の後継[RFC1036]は別のアプローチを標準化するまで、この仕様では、ニュースグループ名にUTF-8が許可されていますがO、彼らはUS-ASCIIに制限する必要があります。彼らは相互運用性の問題を引き起こす可能性があるため、8ビットエンコーディングを使用しないでください。
o The newsgroup description SHOULD be in US-ASCII or UTF-8 unless and until a successor to RFC 1036 standardises other encoding arrangements. 8-bit encodings other than UTF-8 SHOULD NOT be used because they are likely to cause interoperability problems.
RFC 1036の後継は、他の符号化アレンジメントを標準化しないとまではニュースグループの記述は、US-ASCIIまたはUTF-8にする必要がありますoを。彼らは相互運用性の問題を引き起こす可能性があるため、UTF-8以外の8ビットエンコーディングを使用しないでください。
o Implementations that obtain this data from an external source MUST handle it correctly even if it does not meet the above requirements. Implementations (in particular, clients) MUST handle such data correctly.
外部ソースからこのデータを取得Oの実装は、それが上記の要件を満たしていない場合でも、それを正しく処理する必要があります。 （特に、クライアントでの）実装は正しく、そのようなデータを処理する必要があります。
While the primary use of NNTP is for transmitting articles that conform to RFC 1036 (Netnews articles), it is also used for other formats (see Appendix A). It is therefore most appropriate that internationalisation issues related to article formats be addressed in the relevant specifications. For Netnews articles, this is any successor to RFC 1036. For email messages, it is RFC 2822 [RFC2822].
NNTPの主な用途は、1036（ネットニュース記事）をRFCに準拠物品を送信するためのものであるが、それはまた、他のフォーマットのために使用される（付録A参照）。したがって、記事のフォーマットに関連した国際化の問題は、関連する仕様で対処することが最も適切です。ネットニュースの記事については、これは、それはRFC 2822 [RFC2822]で電子メールメッセージのRFC 1036に任意の後継です。
Of course, any article transmitted via NNTP needs to conform to this specification as well.
もちろん、NNTPを経由して送信された記事でもこの仕様に準拠する必要があります。
Restricting newsgroup names to UTF-8 is not a complete solution. In particular, when new newsgroup names are created or a user is asked to enter a newsgroup name, some scheme of canonicalisation will need to take place. This specification does not attempt to define that canonicalization; further work is needed in this area, in conjunction with the article format specifications. Until such specifications are published, implementations SHOULD match newsgroup names octet by octet. It is anticipated that any approved scheme will be applied "at the edges", and therefore octet-by-octet comparison will continue to apply to most, if not all, uses of newsgroup names in NNTP.
UTF-8にニュースグループ名を制限する完全なソリューションではありません。特に、新しいニュースグループ名が作成されるか、ユーザーがニュースグループ名を入力するように要求されたときに、canonicalisationのいくつかの方式では、場所を取る必要があります。この仕様は、その正規化を定義しようとしません。さらに作業は記事のフォーマット仕様と併せて、この分野で必要とされます。そのような仕様が公開されるまで、実装はオクテットでニュースグループ名のオクテットと一致する必要があります。任意の承認スキームが「縁で」適用され、すべてではないが、NNTPでニュースグループ名を使用している場合ので、オクテットごとのオクテットの比較は、最もに引き続き適用されることが予想されます。
In the meantime, any implementation experimenting with UTF-8 newsgroup names is strongly cautioned that a future specification may require that those names be canonicalized when used with NNTP in a way that is not compatible with their experiments.
一方で、UTF-8ニュースグループの名前を試して任意の実装が強く、将来の仕様が彼らの実験と互換性のない方法でNNTPと一緒に使用する場合、それらの名前が正規化されることを必要とするかもしれないと警告しています。
Since the primary use of NNTP is with Netnews, and since newsgroup descriptions are normally distributed through specially formatted articles, it is recommended that the internationalisation issues related to them be addressed in any successor to RFC 1036.
NNTPの主な用途はネットニュースであるので、ニュースグループの説明は、通常、特別な形式の記事を通じて配布されているので、そして、それらに関連する国際化の問題は、RFC 1036に任意の後継で対処することをお勧めします。
This specification requires IANA to keep a registry of capability labels. The initial contents of this registry are specified in Section 3.3.4. As described in Section 3.3.3, labels beginning with X are reserved for private use, while all other names are expected to be associated with a specification in an RFC on the standards track or defining an IESG-approved experimental protocol.
この仕様は、機能ラベルのレジストリを維持するためにIANAが必要です。このレジストリの初期の内容は、セクション3.3.4で指定されています。 3.3.3項で述べたように、他のすべての名称は、標準化トラックやIESGが承認した実験プロトコルの定義のRFCで仕様に関連することが期待される一方で、Xで始まるラベルは、私的使用のために予約されています。
Different entries in the registry MUST use different capability labels.
レジストリ内の異なるエントリは、異なる機能のラベルを使用しなければなりません。
Different entries in the registry MUST NOT use the same command name. For this purpose, variants distinguished by a second or subsequent keyword (e.g., "LIST HEADERS" and "LIST OVERVIEW.FMT") count as different commands. If there is a need for two extensions to use the same command, a single harmonised specification MUST be registered.
レジストリ内の異なるエントリは、同じコマンド名を使用してはなりません。この目的のために、第二またはその後のキーワードによって区別変異体（例えば、「LISTヘッダ」と「一覧OVERVIEW.FMTは」）のような異なるコマンドを数えます。 2つの拡張は、同じコマンドを使用する必要がある場合は、1つの調和のとれた仕様は、登録しなければなりません。
This section is meant to inform application developers, information providers, and users of the security limitations in NNTP as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks.
このセクションでは、この文書で説明するように、アプリケーション開発者、情報提供者、およびNNTPのセキュリティ制限のユーザーに通知するものとします。それはセキュリティリスクを軽減するためのいくつかの提案を行いんが議論は、明らかに問題の決定的な解決策が含まれていません。
NNTP, because it was created to distribute network news articles, will forward whatever information is stored in those articles. Specification of that information is outside this scope of this document, but it is likely that some personal and/or proprietary information is available in some of those articles. It is very important that designers and implementers provide informative warnings to users so that personal and/or proprietary information in material that is added automatically to articles (e.g., in headers) is not disclosed inadvertently. Additionally, effective and easily understood mechanisms to manage the distribution of news articles SHOULD be provided to NNTP Server administrators, so that they are able to report with confidence the likely spread of any particular set of news articles.
NNTP、それはネットワークのニュース記事を配布するために作成されたためには、これらの記事に格納されているものの情報転送します。その情報の仕様は、このドキュメントのこの範囲外ですが、いくつかの個人的なおよび/または専有情報は、これらの記事のいくつかで利用可能であると思われます。 （ヘッダーで、例えば）の記事に自動的に追加された材料で、個人および/または専有情報が誤って記載されていないように、設計者と実装者は、ユーザーに有益な警告を提供することが非常に重要です。彼らは自信を持ってニュース記事の任意の特定のセットの可能性の広がりを報告することができるようにまた、ニュース記事の配信を管理するためのメカニズムを理解しやすく効果的とは、NNTPサーバーの管理者に提供されるべきです。
A server is in the position to save session data about a user's requests that might identify their reading patterns or subjects of interest. This information is clearly confidential in nature, and its handling can be constrained by law in certain countries. People using this protocol to provide data are responsible for ensuring that such material is not distributed without the permission of any individuals that are identifiable by the published results.
サーバーは、自分の読書パターンや興味の対象を特定する可能性があるユーザーの要求に関するセッションデータを保存する立場にあります。この情報は、自然の中で明確に機密であり、その取り扱いが特定の国の法律で制約することができます。データを提供するために、このプロトコルを使っている人は、このような材料が公開された結果によって特定されているすべての人の許可なしに配布されていないことを確実にする責任があります。
There is no user-based or token-based authentication in the basic NNTP specification. Access is normally controlled by server configuration files. Those files specify access by using domain names or IP addresses. However, this specification does permit the creation of extensions to NNTP for such purposes; one such extension is [NNTP-AUTH]. While including such mechanisms is optional, doing so is strongly encouraged.
基本的なNNTP仕様にはユーザベースまたはトークンベースの認証はありません。アクセスは通常、サーバーの構成ファイルによって制御されています。これらのファイルは、ドメイン名またはIPアドレスを使用してアクセスを指定します。しかし、この仕様は、このような目的のためにNNTPへの拡張機能の作成を許可しません。そのような拡張は、[NNTP-AUTH]です。そのようなメカニズムを含むことはオプションですが、そうすることを強く推奨されています。
Other mechanisms are also available. For example, a proxy server could be put in place that requires authentication before connecting via the proxy to the NNTP server.
他のメカニズムも用意されています。たとえば、プロキシサーバーは、NNTPサーバーへのプロキシを経由して接続する前に認証を必要とする場所に置くことができます。
Many existing NNTP implementations authorize incoming connections by checking the IP address of that connection against the IP addresses obtained via DNS lookups of lists of domain names given in local configuration files. Servers that use this type of authentication and clients that find a server by doing a DNS lookup of the server name rely very heavily on the Domain Name Service, and are thus generally prone to security attacks based on the deliberate misassociation of IP addresses and DNS names. Clients and servers need to be cautious in assuming the continuing validity of an IP number/DNS name association.
多くの既存のNNTPの実装は、ローカル構成ファイルで指定したドメイン名のリストのDNSルックアップを介して取得したIPアドレスに対して、その接続のIPアドレスをチェックすることにより、着信接続を許可します。サーバー名のDNSルックアップを実行して、サーバーを見つけ認証とクライアントのこのタイプを使用するサーバーは、ドメインネームサービスに非常に大きく依存し、IPアドレスとDNS名の故意のmisassociationに基づいて、一般的にこのようにセキュリティ攻撃を受け易いです。クライアントとサーバーはIP数/ DNS名協会の継続的な妥当性を仮定して慎重にする必要があります。
In particular, NNTP clients and servers SHOULD rely on their name resolver for confirmation of an IP number/DNS name association, rather than cache the result of previous host name lookups. Many platforms already can cache host name lookups locally when appropriate, and they SHOULD be configured to do so. It is proper for these lookups to be cached, however, only when the TTL (Time To Live) information reported by the name server makes it likely that the cached information will remain useful.
具体的には、NNTPクライアントとサーバは、IP数/ DNS名協会の確認のために自分の名前リゾルバに頼るのではなく、以前のホスト名ルックアップの結果をキャッシュすべきです。適切な場合、多くのプラットフォームでは、すでにローカルホスト名のルックアップをキャッシュすることができ、そして彼らがそうするように設定する必要があります。これらの検索がキャッシュされることはネームサーバによって報告されたTTL（生存時間）の情報が、それはおそらく、キャッシュされた情報が有用残ることになりときにのみ、しかし、適切です。
If NNTP clients or servers cache the results of host name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS. If NNTP clients or servers do not observe this rule, they could be spoofed when a previously accessed server's IP address changes. As network renumbering is expected to become increasingly common, the possibility of this form of attack will increase. Observing this requirement thus reduces this potential security vulnerability.
NNTPクライアントまたはサーバは、パフォーマンスの向上を実現するために、ホスト名ルックアップの結果をキャッシュする場合は、DNSによって報告されたTTL情報を守らなければなりません。 NNTPクライアントまたはサーバがこのルールを守らない場合、彼らは時に以前にアクセスし、サーバーのIPアドレスの変更を詐称することができます。ネットワークリナンバリングがますます一般的になることが予想されるので、この形式の攻撃の可能性が大きくなります。この要件を観察するため、この潜在的なセキュリティ上の脆弱性を低減します。
This requirement also improves the load-balancing behaviour of clients for replicated servers using the same DNS name and reduces the likelihood of a user's experiencing failure in accessing sites that use that strategy.
この要件は、同じDNS名を使用して複製サーバーに対するクライアントのロードバランシングの動作を改善し、その戦略を使用してサイトにアクセスするには、ユーザーの経験故障の可能性を低減します。
UTF-8 [RFC3629] permits only certain sequences of octets and designates others as either malformed or "illegal". The Unicode standard identifies a number of security issues related to illegal sequences and forbids their generation by conforming implementations.
UTF-8 [RFC3629]はオクテットのみ特定の配列を可能にし、不正な形式または「不正」のいずれかとして他のユーザーを指定します。ユニコード規格は、不正配列に関連するセキュリティ問題の数を識別し、実装を適合することによって、それらの生成を禁止します。
Implementations of this specification MUST NOT generate malformed or illegal sequences and SHOULD detect them and take some appropriate action. This could include the following:
この仕様の実装は、不正な形式または不正なシーケンスを生成してはならないし、それらを検出して、いくつかの適切な行動を取る必要があります。これは、次を含めることができます：
o Generating a 501 response code.
501レスポンスコードを生成するO。
o Replacing such sequences by the sequence %xEF.BF.BD, which encodes the "replacement character" U+FFFD.
「置換文字」U + FFFDをコードする配列の％xEF.BF.BDによってこのような配列の交換O。
o Closing the connection.
O接続を閉じます。
o Replacing such sequences by a "guessed" valid sequence (based on properties of the UTF-8 encoding).
「推測」は有効なシーケンスによって、そのような配列を交換O（UTF-8エンコーディングの特性に基づいて）。
In the last case, the implementation MUST ensure that any replacement cannot be used to bypass validity or security checks. For example, the illegal sequence %xC0.A0 is an over-long encoding for space (%x20). If it is replaced by the correct encoding in a command line, this needs to happen before the command line is parsed into individual arguments. If the replacement came after parsing, it would be possible to generate an argument with an embedded space, which is forbidden. Use of the "replacement character" does not have this problem, since it is permitted wherever non-US-ASCII characters are. Implementations SHOULD use one of the first two solutions where the general structure of the NNTP stream remains intact and SHOULD close the connection if it is no longer possible to parse it sensibly.
最後のケースでは、実装は、任意の置換は、有効性やセキュリティチェックを迂回するために使用することができないことを保証しなければなりません。例えば、不正シーケンス％のxC0.A0はスペースのオーバー長い符号（％のX20）です。それは、コマンドラインで正しいエンコーディングに置き換えている場合は、このコマンドラインは、個々の引数に解析される前に発生する必要があります。交換は、解析後に来たならば、禁止されている組み込みスペース、との引数を生成することが可能です。 「置換文字」の使用は非US-ASCII文字は、どこにいても、それが許可されているので、この問題はありません。実装は、NNTPストリームの一般的な構造は無傷のままであり、賢明それを解析することはもはや不可能である場合、接続を閉じる必要があります最初の二つの溶液のいずれかを使用すべきです。
The CAPABILITIES command provides a capability list, which is information about the current capabilities of the server. Whenever there is a relevant change to the server state, the results of this command are required to change accordingly.
capabilitiesコマンドは、サーバの現在の機能に関する情報である機能のリストを提供します。サーバーの状態に関連する変更があるたびに、このコマンドの結果は、それに応じて変更する必要があります。
In most situations, the capabilities list in a given server state will not change from session to session; for example, a given extension will be installed permanently on a server. Some clients may therefore wish to remember which extensions a server supports to avoid the delay of an additional command and response, particularly if they open multiple connections in the same session.
ほとんどの状況では、特定のサーバーの状態での機能のリストは、セッションごとに変更されることはありません。例えば、特定の拡張子は、サーバー上に永続的にインストールされます。一部のクライアントは、したがって、サーバは、彼らが同じセッションで複数の接続を開く場合は特に、追加のコマンドおよびレスポンスの遅延を回避するためにサポートしている拡張モジュールをどの覚えておきたいことがあります。
However, information about extensions related to security and privacy MUST NOT be cached, since this could allow a variety of attacks.
これは、さまざまな攻撃を許す可能性があるためしかし、セキュリティとプライバシーに関連する拡張機能に関する情報は、キャッシュされてはなりません。
For example, consider a server that permits the use of cleartext passwords on links that are encrypted but not otherwise:
例えば、そうでない場合は、暗号化されていませんが、リンク上の平文パスワードの使用を許可するサーバーを考えてみます。
[Initial connection set-up completed.] [S] 200 NNTP Service Ready, posting permitted [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] NEWNEWS [S] POST [S] XENCRYPT [S] LIST ACTIVE NEWSGROUPS [S] . [C] XENCRYPT [Client and server negotiate encryption on the link] [S] 283 Encrypted link established
[初期接続セットアップが完了。] [S] 200 NNTPサービス準備、許可[C]の機能を投稿[S] 101の能力リスト：[S] VERSION 2 [S] READER [S] NEWNEWS [S] POST [S] XENCRYPT [S] LIST ACTIVE NEWSGROUPS [S]。 [C] XENCRYPT [クライアントとサーバーがリンク上で暗号化をネゴシエート] [S] 283暗号化されたリンク確立
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] NEWNEWS [S] POST [S] XSECRET [S] LIST ACTIVE NEWSGROUPS [S] . [C] XSECRET fred flintstone [S] 290 Password for fred accepted
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] NEWNEWS [S] POST [S] XSECRET [S] LIST ACTIVE NEWSGROUPS [S]。 [C] XSECRETフレッドフリントストーンは、[S]フレッド290パスワードが受け入れられ
If the client caches the last capabilities list, then on the next session it will attempt to use XSECRET on an unencrypted link:
クライアントは最後の能力リストをキャッシュする場合は、次のセッションでは、暗号化されていないリンクでXSECRETを使用しようとします：
[Initial connection set-up completed.] [S] 200 NNTP Service Ready, posting permitted [C] XSECRET fred flintstone [S] 483 Only permitted on secure links
[初期接続セットアップが完了しました。] [S] 200 NNTPサービスの準備、許可[C] XSECRETフレッド・フリントストーン[S] 483だけが安全なリンクの許可を掲示
This exposes the password to any eavesdropper. While the primary cause of this is passing a secret without first checking the security of the link, caching of capability lists can increase the risk.
これは、任意の盗聴者にパスワードを公開します。この主な原因は、最初のリンクの安全性を確認せずに秘密を渡している間に、機能リストのキャッシングはリスクを増大させることができます。
Any security extension should include requirements to check the security state of the link in a manner appropriate to that extension.
任意のセキュリティ拡張機能は、その拡張子に適切な方法でリンクのセキュリティ状態をチェックするための要件を含める必要があります。
Caching should normally only be considered for anonymous clients that do not use any security or privacy extensions and for which the time required for an additional command and response is a noticeable issue.
キャッシングは通常、唯一の任意のセキュリティやプライバシーの拡張機能を使用して、追加のコマンドと応答に要する時間が顕著な問題であるためにはありません匿名のクライアントのために考慮されるべきです。
This document is the result of much effort by the present and past members of the NNTP Working Group, chaired by Russ Allbery and Ned Freed. It could not have been produced without them.
この文書では、ラスAllberyとネッドフリードが議長を務めるNNTPワーキンググループの現在および過去のメンバーから多くの努力の結果です。それは彼らなしで生産されていることができませんでした。
The author acknowledges the original authors of NNTP as documented in RFC 977 [RFC977]: Brian Kantor and Phil Lapsey.
ブライアン・カンターとフィル・Lapsey：RFC 977 [RFC977]に記載されているように、著者は、NNTPの原作者を認めています。
The author gratefully acknowledges the following:
作者は感謝して次のことを認めて：
o The work of the NNTP committee chaired by Eliot Lear. The organization of this document was influenced by the last available version from this working group. A special thanks to Eliot for generously providing the original machine-readable sources for that document.
エリオット・リアが議長を務めNNTP委員会の作業O。このドキュメントの組織は、このワーキンググループから使用可能な最後のバージョンに影響を受けました。寛大にその文書の元の機械可読のソースを提供するためのエリオットへの特別な感謝。
o The work of the DRUMS working group, specifically RFC 1869 [RFC1869], that drove the original thinking that led to the CAPABILITIES command and the extensions mechanism detailed in this document.
capabilitiesコマンドおよび本書で詳述拡張機構につながったオリジナルの思考を運転したDRUMSワーキンググループ、特にRFC 1869 [RFC1869]、の作業O。
o The authors of RFC 2616 [RFC2616] for providing specific and relevant examples of security issues that should be considered for HTTP. Since many of the same considerations exist for NNTP, those examples that are relevant have been included here with some minor rewrites.
HTTPのために考慮すべきセキュリティ上の問題の特定と関連する例を提供するためのRFC 2616 [RFC2616]の著者、O。同じ考慮の多くは、NNTPのために存在しているため、関連するこれらの例は、いくつかのマイナーな書き換えにここに含まれています。
o The comments and additional information provided by the following individuals in preparing one or more of the progenitors of this document:
このドキュメントの前駆細胞の一つ以上を製造する際に以下の個人が提供するコメントや追加情報O：
Russ Allbery <rra@stanford.edu>
Wayne Davison <davison@armory.com>
Chris Lewis <clewis@bnr.ca>
Tom Limoncelli <tal@mars.superlink.net>
Eric Schnoebelen <eric@egsner.cirr.com>
Rich Salz <rsalz@osf.org>
This work was motivated by the work of various news reader authors and news server authors, including those listed below:
この作品は、以下に列挙したものなど、さまざまなニュースリーダーの作成者とニュースサーバの作者の作品によって動機づけられました。
Rick Adams Original author of the NNTP extensions to the RN news reader and last maintainer of Bnews.
RNニュースリーダーとBnewsの最後のメンテナにNNTP拡張子のリック・アダムス原作。
Stan Barber Original author of the NNTP extensions to the news readers that are part of Bnews.
Bnewsの一部であるニュースの読者にNNTP拡張子のスタン・バーバー原作。
Geoff Collyer Original author of the OVERVIEW database proposal and one of the original authors of CNEWS.
ジェフ・コルヤー概要データベースの提案とCNEWSの原作者の1の原作。
Dan Curry Original author of the xvnews news reader.
xvnewsニュースリーダーのダンカレー原作。
Wayne Davison Author of the first threading extensions to the RN news reader (commonly called TRN).
RNニュースリーダー（通称TRN）への最初のスレッドの拡張のウェイン・デイヴィソン著者。
Geoff Huston Original author of ANU NEWS.
ジェフ・ヒューストンANU NEWSの原作。
Phil Lapsey Original author of the UNIX reference implementation for NNTP.
NNTPのためのUNIXリファレンス実装のフィル・Lapsey原作。
Iain Lea Original maintainer of the TIN news reader.
TINニュースリーダーのイアン・リーオリジナルのメンテナ。
Chris Lewis First known implementer of the AUTHINFO GENERIC extension.
クリス・ルイスまずAUTHINFO GENERIC拡張の実装を知られています。
Rich Salz Original author of INN.
INNのリッチ・サルズ原作者。
Henry Spencer One of the original authors of CNEWS.
ヘンリー・スペンサーCNEWSの原作者の一つ。
Kim Storm Original author of the NN news reader.
NNニュースリーダーのキム・ストーム原作。
Other people who contributed to this document include:
この文書に貢献し、他の人は、次のとおりです。
Matthias Andree Greg Andruk Daniel Barclay Maurizio Codogno Mark Crispin Andrew Gierth Juergen Helbing Scott Hollenbeck Urs Janssen Charles Lindsey Ade Lovett David Magda Ken Murchison Francois Petillon Peter Robinson Rob Siemborski Howard Swinehart Ruud van Tol Jeffrey Vinocur Erik Warmelink
マティアス・アンドレグレッグAndrukダニエル・バークレーマウリツィオコドーニョマーク・クリスピンアンドリューGierthユルゲンHelbingスコットホレンベックウルス・ヤンセンチャールズリンジーアデラヴェットデビッドマグダケンマーチソンフランソワPetillonピーター・ロビンソンロブSiemborskiハワードSwinehartルードバンのTolジェフリーVinocurエリックWarmelink
The author thanks them all and apologises to anyone omitted.
著者のおかげで、それらすべては、省略誰にも謝ります。
Finally, the present author gratefully acknowledges the vast amount of work put into previous versions by the previous author:
最後に、本の著者は感謝、前の作者が以前のバージョンに入れ仕事の膨大な量を認めます：
Stan Barber <sob@academ.com>
スタン・バーバー<sob@academ.com>
[ANSI1986] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ANSI1986]米国規格協会は、「コード化文字セット - 情報交換のための7ビットの米国標準コード」、ANSI X3.4、1986。
[RFC977] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[RFC977]カンター、B.およびP.ラプスリー、 "ネットワークニュース転送プロトコル"、RFC 977、1986年2月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[TF.686-1] International Telecommunications Union - Radio, "Glossary, ITU-R Recommendation TF.686-1", ITU-R Recommendation TF.686-1, October 1997.
[TF.686-1]国際電気通信連合 - ラジオ、 "用語集、ITU-R勧告TF.686-1"、ITU-R勧告TF.686-1、1997年10月。
[NNTP-AUTH] Vinocur, J., Murchison, K., and C. Newman, "Network News Transfer Protocol (NNTP) Extension for Authentication", RFC 4643, October 2006.
[NNTP-AUTH] Vinocur、J.、マーチソン、K.、およびC.ニューマン、 "認証のためのネットワークニュース転送プロトコル（NNTP）拡張子"、RFC 4643、2006年10月。
[NNTP-STREAM] Vinocur, J. and K. Murchison, "Network News Transfer Protocol (NNTP) Extension for Streaming Feeds", RFC 4644, October 2006.
[NNTP-STREAM] Vinocur、J.およびK.マーチソン、 "ストリーミングフィードのためのネットワークニュース転送プロトコル（NNTP）拡張子"、RFC 4644、2006年10月。
[NNTP-TLS] Murchison, K., Vinocur, J., and C. Newman, "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", RFC 4642, October 2006.
[NNTP-TLS]マーチソン、K.、Vinocur、J.、およびC.ニューマン、RFC 4642、2006年10月 "ネットワークニュース転送プロトコル（NNTP）とトランスポート層セキュリティ（TLS）を使用します"。
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
、RFC 1036、1987年12月 "USENETメッセージの交換のための標準的な" [RFC1036]ホートン、M.およびR.アダムス。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[RFC1869] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、 "SMTPサービス拡張"、STD 10、RFC 1869、1995年11月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]ローズ、M.、 "ライティングI-DSおよびXMLを使用しているRFC"、RFC 2629、1999年6月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[RFC2980]バーバー、S.、 "共通NNTP拡張機能"、RFC 2980、2000年10月。
[ROBE1995] Robertson, R., "FAQ: Overview database / NOV General Information", January 1995.
[ROBE1995]ロバートソン、R.、 "FAQ：概要データベース/ 11月一般情報"、1995年1月。
There is no definitive copy of this document known to
the author. It was previously posted as the Usenet
article <news:nov-faq-1-930909720@agate.Berkeley.EDU>
[SALZ1992] Salz, R., "Manual Page for wildmat(3) from the INN 1.4 distribution, Revision 1.10", April 1992.
[SALZ1992] Salzの、R.、1992年4月 "INN 1.4分布、リビジョン1.10からWILDMAT（3）のマニュアルページ"。
There is no definitive copy of this document known to
the author.
Appendix A. Interaction with Other Specifications
その他の仕様と付録A.相互作用
NNTP is most often used for transferring articles that conform to RFC 1036 [RFC1036] (such articles are called "Netnews articles" here). It is also sometimes used for transferring email messages that conform to RFC 2822 [RFC2822] (such articles are called "email articles" here). In this situation, articles must conform both to this specification and to that other one; this appendix describes some relevant issues.
NNTPは、ほとんどの場合、RFC 1036 [RFC1036]（このような製品は、ここでは「ネットニュースの記事」と呼ばれている）に準拠する記事を転送するために使用されます。また、時にはRFC 2822に準拠した電子メールメッセージを転送するために使用される[RFC2822]（このような製品は、ここでは、「電子メールの記事」と呼ばれています）。このような状況では、記事がこの仕様にし、そのもう一方の両方に準拠している必要があります。この付録では、いくつかの関連問題について説明します。
A.1. Header Folding
A.1。ヘッダー折りたたみ
NNTP allows a header line to be folded (by inserting a CRLF pair) before any space or TAB character.
NNTPは、任意のスペースまたはタブ文字の前（CRLFペアを挿入することによって）ヘッダー行が折り畳まれることを可能にします。
Both email and Netnews articles are required to have at least one octet other than space or TAB on each header line. Thus, folding can only happen at one point in each sequence of consecutive spaces or TABs. Netnews articles are further required to have the header name, colon, and following space all on the first line; folding may only happen beyond that space. Finally, some non-conforming software will remove trailing spaces and TABs from a line. Therefore, it might be inadvisable to fold a header after a space or TAB.
どちらも電子メールやネットニュースの記事は、各ヘッダ行にスペースまたはTAB以外の少なくとも1つのオクテットを持つことが必要とされています。したがって、折りのみ連続したスペースまたはタブの各配列中の一点で起こり得ます。ネットニュースの記事は、さらに、前記第1のライン上のすべてのヘッダ名、コロン、および以下のスペースが必要とされています。折りたたみはそのスペースを超えて発生する可能性があります。最後に、いくつかの非準拠のソフトウェアがラインから末尾のスペースとタブを削除します。したがって、スペースまたはTAB後のヘッダを折るためにはお勧めできませんかもしれません。
For maximum safety, header lines SHOULD conform to the following syntax rather than to that in Section 9.7.
最大の安全のために、ヘッダー行は、以下の構文にではなく、セクション9.7のものに準拠している必要があり。
header = header-name ":" SP [header-content] CRLF header-content = [WS] token *( [CRLF] WS token )
ヘッダ=ヘッダ名 "：" SP [ヘッダーコンテンツ] CRLFヘッダーコンテンツ= [WS]トークン*（[CRLF] WSトークン）
A.2. Message-IDs
A.2。メッセージのID
Every article handled by an NNTP server MUST have a unique message-id. For the purposes of this specification, a message-id is an arbitrary opaque string that merely needs to meet certain syntactic requirements and is just a way to refer to the article.
NNTPサーバで処理すべての記事は、ユニークなメッセージIDを持っていなければなりません。本明細書の目的のために、メッセージIDは、単に特定の構文上の要件を満たすために必要と記事を参照するだけの方法である任意の不透明な文字列です。
Because there is a significant risk that old articles will be reinjected into the global Usenet system, RFC 1036 [RFC1036] requires that message-ids are globally unique for all time.
古い記事は、グローバルなUsenetシステムに再注入されるという重大なリスクがあるので、RFC 1036 [RFC1036]は、メッセージIDは、すべての時間のためにグローバルにユニークである必要があります。
This specification states that message-ids are the same if and only if they consist of the same sequence of octets. Other specifications may define two different sequences as being equal because they are putting an interpretation on particular characters. RFC 2822 [RFC2822] has a concept of "quoted" and "escaped" characters. It therefore considers the three message-ids:
この仕様は、彼らがオクテットの同じ配列からなる場合にのみ場合、メッセージIDが同じであることを述べています。その他の仕様は、彼らは、特定の文字の解釈を入れているので、等しいように2つの異なる配列を定義することができます。 RFC 2822 [RFC2822]は、「引用符で囲まれた」との文字を「エスケープ」の概念があります。したがって、3つのメッセージ-idを考慮します。
<ab.cd@example.com> <"ab.cd"@example.com> <"ab.\cd"@example.com>
<Ab.cd@example.com> < "ab.cd" @ example.com> < "AB。\ Cdの" @ example.com>
as being identical. Therefore, an NNTP implementation handing email articles must ensure that only one of these three appears in the protocol and that the other two are converted to it as and when necessary, such as when a client checks the results of a NEWNEWS command against an internal database of message-ids. Note that RFC 1036 [RFC1036] never treats two different strings as being identical. Its successor (as of the time of writing) restricts the syntax of message-ids so that, whenever RFC 2822 would treat two strings as equivalent, only one of them is valid (in the above example, only the first string is valid).
同一であるとして。そのため、NNTPの実装手渡した電子メールの記事は、プロトコルにおけるこれら三つの現れの一つだけということと、必要なときに他の二つは、クライアントが内部データベースに対してNEWNEWSコマンドの結果をチェックするときのように、としてそれに変換されていることをを確認する必要がありますメッセージIDの。そのRFC 1036 [RFC1036]は同一であるように2つの異なる文字列を扱うことはありません注意してください。 RFC 2822は同等のように2つの文字列を扱いますいつでも、なるように（執筆時のように）その後継は、メッセージIDの構文を制限し、そのうちの一つだけは、（上記の例では、最初の文字列が有効である）が有効です。
This specification does not describe how the message-id of an article is determined; it may be deduced from the contents of the article or derived from some external source. If the server is also conforming to another specification that contains a definition of message-id compatible with this one, the server SHOULD use those message-ids. A common approach, and one that SHOULD be used for email and Netnews articles, is to extract the message-id from the contents of a header with name "Message-ID". This may not be as simple as copying the entire header contents; it may be necessary to strip off comments and undo quoting, or to reduce "equivalent" message-ids to a canonical form.
本明細書は、物品のメッセージIDを決定する方法を記載していません。それは記事の内容から推測されるか、いくつかの外部ソースに由来することができます。サーバはまた、このいずれかと互換性のあるメッセージIDの定義を含む別の仕様に準拠している場合、サーバはそれらのメッセージIDを使用するべきです。一般的なアプローチ、および電子メールやネットニュース記事のために使用されるべきものは、名称「メッセージID」とヘッダの内容から、メッセージIDを抽出することです。これは、全体のヘッダーの内容をコピーするのと同じくらい簡単ではないかもしれません。コメントを取り除き、引用元に戻す、または標準形式に「等価」メッセージIDを減少させることが必要であり得ます。
If an article is obtained through the IHAVE command, there will be a message-id provided with the command. The server MAY either use it or determine one from the article contents. However, whichever it does, it SHOULD ensure that, if the IHAVE command is repeated with the same argument and article, it will be recognized as a duplicate.
物品がIHAVEコマンドを介して取得された場合、コマンドを備えたメッセージIDが存在することになります。サーバはどちらかそれを使用するか、記事の内容から1を決定することができます。しかし、それがない方、それはIHAVEコマンドは同じ引数と記事で繰り返されている場合、それは重複として認識されることを保証すべきです。
If an article does not contain a message-id that the server can identify, it MUST synthesize one. This could, for example, be a simple sequence number or be based on the date and time when the article arrived. When email or Netnews articles are handled, a Message-ID header SHOULD be added to ensure global consistency and uniqueness.
記事では、サーバーが識別できるメッセージIDが含まれていない場合、それは1を合成しなければなりません。これは、例えば、簡単なシーケンス番号である可能性や、物品が到着したときの日時に基づくこと。メールやネットニュース記事が処理されるとき、メッセージ-IDヘッダは、グローバル一貫性と一意性を確保するために添加されるべきです。
Note that, because the message-id might not have been derived from the Message-ID header in the article, the following example is legitimate (though unusual):
メッセージIDは、記事のメッセージIDヘッダから誘導されていない可能性があるため、次の例では、（珍しいが）正当であることに注意してください。
[C] HEAD <45223423@example.com> [S] 221 0 <45223423@example.com> [S] Path: pathost!demo!whitehouse!not-for-mail [S] Message-ID: <1234@example.net> [S] From: "Demo User" <nobody@example.net> [S] Newsgroups: misc.test [S] Subject: I am just a test article [S] Date: 6 Oct 1998 04:38:40 -0500 [S] Organization: An Example Net, Uncertain, Texas [S] .
[C] HEAD <45223423@example.com> [S] 221 0 <45223423@example.com> [S]のパス：！！！pathostデモホワイトハウスではない-用メール[S]メッセージ-ID：<1234例@ .NET> [S]から： "デモ・ユーザー" <nobody@example.net> [S]ニュースグループ：misc.test [S]件名：1998年10月6日4時38分：私はちょうどテスト品[S]日午前： 40 -0500 [S]組織：例ネット、不確かな、テキサス[S]。
A.3. Article Posting
A.3。記事の投稿
As far as NNTP is concerned, the POST and IHAVE commands provide the same basic facilities in a slightly different way. However, they have rather different intentions.
限りNNTPに関しては、POSTとIHAVEコマンドは少し異なる方法で同じ基本的な機能を提供します。しかし、彼らはかなり異なる意図を持っています。
The IHAVE command is intended for transmitting conforming articles between a system of NNTP servers, with all articles perhaps also conforming to another specification (e.g., all articles are Netnews articles). It is expected that the client will already have done any necessary validation (or that it has in turn obtained the article from a third party that has done so); therefore, the contents SHOULD be left unchanged.
IHAVEコマンドは、おそらく、別の仕様に準拠するすべての記事と、NNTPサーバのシステムとの間の適合品を送信するために意図されている（例えば、すべての記事は、ネットニュース記事です）。クライアントが既に任意の必要な検証を行っているということ（あるいは、それが今度はそうした第三者からの記事を取得していることを）期待されています。そのため、内容はそのまま残しておく必要があります。
In contrast, the POST command is intended for use when an end-user is injecting a newly created article into a such a system. The article being transferred might not be a conforming email or Netnews article, and the server is expected to validate it and, if necessary, to convert it to the right form for onward distribution. This is often done by a separate piece of software on the server installation; if so, the NNTP server SHOULD pass the incoming article to that software unaltered, making no attempt to filter characters, to fold or limit lines, or to process the incoming text otherwise.
対照的に、POSTコマンドは、エンドユーザがこのようなシステムに新たに作成された物品を注入された使用のために意図されています。転送されている記事は適合し、電子メールやネットニュースの記事ではないかもしれません、そしてサーバーが必要な場合は以降配信のために右のフォームに変換し、それを検証し、することが期待されます。これは多くの場合、サーバーのインストールのソフトウェアの別の部分によって行われます。もしそうなら、NNTPサーバは、折ったりリミットライン、あるいは、着信テキストを処理するために、文字をフィルタリングする試みを行っていない、変更されていないそのソフトウェアへの着信の記事を渡す必要があります。
The POST command can fail in various ways, and clients should be prepared to re-send an article. When doing so, however, it is often important to ensure (as far as possible) that the same message-id is allocated to both attempts so that the server, or other servers, can recognize the two articles as duplicates. In the case of email or Netnews articles, therefore, the posted article SHOULD contain a header with the name "Message-ID", and the contents of this header SHOULD be identical on each attempt. The server SHOULD ensure that two POSTed articles with the same contents for this header are recognized as identical and that the same message-id is allocated, whether or not those contents are suitable for use as the message-id.
POSTコマンドは、さまざまな方法で失敗すること、およびクライアントは、物品を再送信するために準備する必要があります。その際、しかし、サーバ、または他のサーバは、重複などの2件の記事を認識できるように同じメッセージIDが両方の試みに割り当てられていること（可能な限り）ことが多いようにすることが重要です。電子メールやネットニュースの記事の場合には、そのため、掲載記事は、名前「メッセージID」を持つヘッダが含まれている必要があり、このヘッダの内容は、各試行で同一でなければなりません。サーバは、このヘッダーのため、同じ内容を持つ2つのPOSTさ物品が同一であり、同じメッセージIDがその内容がメッセージIDとして使用するのに適しているかどうか、割り当てられていると認識されていることを確実にすべきです。
Appendix B. Summary of Commands
コマンドの付録B.概要
This section contains a list of every command defined in this document, ordered by command name and by indicating capability.
このセクションでは、コマンド名によってと能力を示すことによって注文し、この文書で定義されたすべてのコマンドのリストが含まれています。
Ordered by command name:
コマンド名によって命じました：
+-------------------+-----------------------+---------------+
| Command | Indicating capability | Definition |
+-------------------+-----------------------+---------------+
| ARTICLE | READER | Section 6.2.1 |
| BODY | READER | Section 6.2.3 |
| CAPABILITIES | mandatory | Section 5.2 |
| DATE | READER | Section 7.1 |
| GROUP | READER | Section 6.1.1 |
| HDR | HDR | Section 8.5 |
| HEAD | mandatory | Section 6.2.2 |
| HELP | mandatory | Section 7.2 |
| IHAVE | IHAVE | Section 6.3.2 |
| LAST | READER | Section 6.1.3 |
| LIST | LIST | Section 7.6.1 |
| LIST ACTIVE.TIMES | LIST | Section 7.6.4 |
| LIST ACTIVE | LIST | Section 7.6.3 |
| LIST DISTRIB.PATS | LIST | Section 7.6.5 |
| LIST HEADERS | HDR | Section 8.6 |
| LIST NEWSGROUPS | LIST | Section 7.6.6 |
| LIST OVERVIEW.FMT | OVER | Section 8.4 |
| LISTGROUP | READER | Section 6.1.2 |
| MODE READER | MODE-READER | Section 5.3 |
| NEWGROUPS | READER | Section 7.3 |
| NEWNEWS | NEWNEWS | Section 7.4 |
| NEXT | READER | Section 6.1.4 |
| OVER | OVER | Section 8.3 |
| POST | POST | Section 6.3.1 |
| QUIT | mandatory | Section 5.4 |
| STAT | mandatory | Section 6.2.4 |
+-------------------+-----------------------+---------------+
Ordered by indicating capability:
能力を示すことにより、注文しました：
+-------------------+-----------------------+---------------+
| Command | Indicating capability | Definition |
+-------------------+-----------------------+---------------+
| CAPABILITIES | mandatory | Section 5.2 |
| HEAD | mandatory | Section 6.2.2 |
| HELP | mandatory | Section 7.2 |
| QUIT | mandatory | Section 5.4 |
| STAT | mandatory | Section 6.2.4 |
| HDR | HDR | Section 8.5 |
| LIST HEADERS | HDR | Section 8.6 |
| IHAVE | IHAVE | Section 6.3.2 |
| LIST | LIST | Section 7.6.1 |
| LIST ACTIVE | LIST | Section 7.6.3 |
| LIST ACTIVE.TIMES | LIST | Section 7.6.4 |
| LIST DISTRIB.PATS | LIST | Section 7.6.5 |
| LIST NEWSGROUPS | LIST | Section 7.6.6 |
| MODE READER | MODE-READER | Section 5.3 |
| NEWNEWS | NEWNEWS | Section 7.4 |
| OVER | OVER | Section 8.3 |
| LIST OVERVIEW.FMT | OVER | Section 8.4 |
| POST | POST | Section 6.3.1 |
| ARTICLE | READER | Section 6.2.1 |
| BODY | READER | Section 6.2.3 |
| DATE | READER | Section 7.1 |
| GROUP | READER | Section 6.1.1 |
| LAST | READER | Section 6.1.3 |
| LISTGROUP | READER | Section 6.1.2 |
| NEWGROUPS | READER | Section 7.3 |
| NEXT | READER | Section 6.1.4 |
+-------------------+-----------------------+---------------+
Appendix C. Summary of Response Codes
応答コードの付録C.まとめ
This section contains a list of every 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 100 (multi-line) Generated by: HELP Meaning: help text follows.
HELP意味：ヘルプテキストは、次によって生成された応答コード100（複数行）。
Response code 101 (multi-line) Generated by: CAPABILITIES Meaning: capabilities list follows.
機能のリストを次の意味機能：によって生成された応答コード101（マルチライン）。
Response code 111 Generated by: DATE 1 argument: yyyymmddhhmmss Meaning: server date and time.
DATE 1引数：YYYYMMDDHHMMSS意味：サーバーの日付と時刻によって生成された応答コード111。
Response code 200 Generated by: initial connection, MODE READER Meaning: service available, posting allowed.
初期接続、MODEのREADER意味：サービスが利用でき、許可を掲載することにより生成された応答コード200。
Response code 201 Generated by: initial connection, MODE READER Meaning: service available, posting prohibited.
初期接続、MODEのREADER意味：サービスが利用でき、禁止掲載することにより生成された応答コード201。
Response code 205 Generated by: QUIT Meaning: connection closing (the server immediately closes the connection).
生成された応答コード205：コネクションクローズ（サーバーはすぐに接続を閉じる）：意味QUIT。
Response code 211 The 211 response code has two completely different forms, depending on which command generated it:
応答コード211は、211応答コードは、に応じて生成されたコマンド、2つの完全に異なる形態を有します。
(not multi-line)
Generated by: GROUP
4 arguments: number low high group
Meaning: group selected.
(multi-line) Generated by: LISTGROUP 4 arguments: number low high group Meaning: article numbers follow.
（マルチライン）によって生成：LISTGROUP 4つの引数：番号低高いグループ意味：文書番号が続きます。
Response code 215 (multi-line) Generated by: LIST Meaning: information follows.
情報は、次の意味LIST：によって生成された応答コード215（マルチライン）。
Response code 220 (multi-line) Generated by: ARTICLE 2 arguments: n message-id Meaning: article follows.
ARTICLE 2つの引数：NメッセージID意味：記事は、以下によって生成された応答コード220（マルチライン）。
Response code 221 (multi-line) Generated by: HEAD 2 arguments: n message-id Meaning: article headers follow.
応答コード221（マルチライン）によって生成：HEAD 2つの引数：NメッセージID意味：記事ヘッダが続きます。
Response code 222 (multi-line) Generated by: BODY 2 arguments: n message-id Meaning: article body follows.
BODY 2つの引数：NメッセージID意味：記事の本文は、以下によって生成された応答コード222（マルチライン）。
Response code 223 Generated by: LAST, NEXT, STAT 2 arguments: n message-id Meaning: article exists and selected.
LAST、NEXT、STAT 2つの引数：によって生成された応答コード223 NメッセージID意味：記事が存在し、選択されました。
Response code 224 (multi-line) Generated by: OVER Meaning: overview information follows.
意味OVER：概要情報は、以下によって生成された応答コード224（マルチライン）。
Response code 225 (multi-line) Generated by: HDR Meaning: headers follow.
HDR意味：によって生成された応答コード225（マルチライン）のヘッダが続きます。
Response code 230 (multi-line) Generated by: NEWNEWS Meaning: list of new articles follows.
NEWNEWS意味：：によって生成された応答コード230（マルチライン）新しい記事の一覧を以下に示します。
Response code 231 (multi-line) Generated by: NEWGROUPS Meaning: list of new newsgroups follows.
新しいニュースグループのリストを、次のとおりです。意味NEWGROUPS：によって生成された応答コード231（複数行）。
Response code 235 Generated by: IHAVE (second stage) Meaning: article transferred OK.
IHAVE（第2段階）の意味：によって生成された応答コード235物品がOK移しました。
Response code 240 Generated by: POST (second stage) Meaning: article received OK.
POST（第2段階）の意味：によって生成された応答コード240物品がOK受信。
Response code 335 Generated by: IHAVE (first stage) Meaning: send article to be transferred.
IHAVE（第一段階）意味：によって生成された応答コード335転送する記事を送信します。
Response code 340 Generated by: POST (first stage) Meaning: send article to be posted.
生成された応答コード340：POST（第一段階）意味：掲載される記事を送信します。
Response code 400 Generic response and generated by initial connection Meaning: service not available or no longer available (the server immediately closes the connection).
レスポンスコード400一般的な応答と初期接続意味によって生成された：（サーバーはすぐに接続を閉じる）サービス利用可能か、もはや利用できません。
Response code 401 Generic response 1 argument: capability-label Meaning: the server is in the wrong mode; the indicated capability should be used to change the mode.
レスポンスコード401一般的な応答1つの引数：機能ラベルの意味：サーバーが誤ったモードです。示された機能は、モードを変更するために使用されるべきです。
Response code 403 Generic response Meaning: internal fault or problem preventing action being taken.
レスポンスコード403一般的な応答の意味：内部障害や問題防止措置が取られています。
Response code 411 Generated by: GROUP, LISTGROUP Meaning: no such newsgroup.
GROUP、LISTGROUP意味：：いいえ、そのようなニュースグループによって生成された応答コード411。
Response code 412 Generated by: ARTICLE, BODY, GROUP, HDR, HEAD, LAST, LISTGROUP, NEXT, OVER, STAT Meaning: no newsgroup selected.
ARTICLE、BODY、GROUP、HDR、HEAD、LAST、LISTGROUP、NEXT、OVER、STAT意味：：によって生成された応答コード412ニュースグループが選択されていません。
Response code 420 Generated by: ARTICLE, BODY, HDR, HEAD, LAST, NEXT, OVER, STAT Meaning: current article number is invalid.
ARTICLE、BODY、HDR、HEAD、LAST、NEXT、OVER、STAT意味：：によって生成された応答コード420現在の記事番号が無効です。
Response code 421 Generated by: NEXT Meaning: no next article in this group.
次の意味：：によって生成された応答コード421このグループ内で無次の記事。
Response code 422 Generated by: LAST Meaning: no previous article in this group.
LAST意味：：によって生成された応答コード422このグループの以前の記事。
Response code 423 Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT Meaning: no article with that number or in that range.
ARTICLE、BODY、HDR、HEAD、OVER、STATの意味：その番号を持つか、その範囲内にありません記事によって生成された応答コード423。
Response code 430 Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT Meaning: no article with that message-id.
ARTICLE、BODY、HDR、HEAD、OVER、STATの意味：そのメッセージ-idを持つノー記事によって生成された応答コード430。
Response code 435 Generated by: IHAVE (first stage) Meaning: article not wanted.
意味IHAVE（第一段階）：レスポンスコードによって生成された435の記事がありません望んでいました。
Response code 436 Generated by: IHAVE (either stage) Meaning: transfer not possible (first stage) or failed (second stage); try again later.
IHAVE（ステージのいずれか）を意味：応答コード436はによって生成可能でない転送（第一段階）または失敗（第2ステージ）。あとでもう一度試してみてください。
Response code 437 Generated by: IHAVE (second stage) Meaning: transfer rejected; do not retry.
IHAVE（第2段階）の意味：によって生成された応答コード437の転送が拒否。再試行しません。
Response code 440 Generated by: POST (first stage) Meaning: posting not permitted.
POST（第一段階）意味：投稿許可しないことによって生成された応答コード440。
Response code 441 Generated by: POST (second stage) Meaning: posting failed.
生成された応答コード441：POST（第2段階）意味：投稿に失敗しました。
Response code 480 Generic response Meaning: command unavailable until the client has authenticated itself.
レスポンスコード480一般的な応答の意味：クライアントまで使用できないコマンドが自身を認証しました。
Response code 483 Generic response Meaning: command unavailable until suitable privacy has been arranged.
レスポンスコード483一般的な応答の意味：適しプライバシーまで使用できないコマンドが配置されています。
Response code 500 Generic response Meaning: unknown command.
レスポンスコード500一般的な応答の意味：不明なコマンド。
Response code 501 Generic response Meaning: syntax error in command.
レスポンスコード501一般的な応答の意味：コマンドでの構文エラー。
Response code 502 Generic response and generated by initial connection
応答コード502ジェネリック応答と初期接続によって生成されました
Meaning for the initial connection and the MODE READER command: service permanently unavailable (the server immediately closes the connection).
サービス恒久的に利用できない（サーバーはすぐに接続を閉じる）：初期接続とモードREADERコマンドの意味。
Meaning for all other commands: command not permitted (and there is no way for the client to change this).
他のすべてのコマンドのための意味：コマンドが許可されていない（と、クライアントはこれを変更する方法はありません）。
Response code 503 Generic response Meaning: feature not supported.
レスポンスコード503一般的な応答は意味：機能はサポートされていません。
Response code 504 Generic response Meaning: error in base64-encoding [RFC4648] of an argument.
応答コード504汎用応答意味：引数のbase64で符号化におけるエラー[RFC4648]。
Appendix D. Changes from
付録D.変更から
In general every attempt has been made to ensure that the protocol specification in this document is compatible with the version specified in RFC 977 [RFC977] and the various facilities adopted from RFC 2980 [RFC2980]. However, there have been a number of changes, some compatible and some not.
一般に、すべての試みは、この文書に記載されているプロトコル仕様は、RFC 977 [RFC977]で指定されたバージョンとRFC 2980 [RFC2980]から採用し、様々な設備と互換性があることを保証するためになされました。ただし、変更の数、いくつかの互換性およびいくつかではないがありました。
This appendix lists these changes. It is not guaranteed to be exhaustive or correct and MUST NOT be relied on.
この付録では、これらの変更を示しています。網羅的に正しいことが保証されていないと当てにしてはなりません。
o A formal syntax specification (Section 9) has been added.
正式な構文仕様（第9節）Oが追加されました。
o The default character set is changed from US-ASCII [ANSI1986] to UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8). This matter is discussed further in Section 10.
Oデフォルトの文字セットがUTF-8 [RFC3629]にUS-ASCII [ANSI1986]から変更された（US-ASCIIがUTF-8のサブセットであることに注意してください）。この問題は、第10章で詳しく説明されています。
o All articles are required to have a message-id, eliminating the "<0>" placeholder used in RFC 977 in some responses.
Oすべての記事は、いくつかの応答にRFC 977で使用される「<0>」プレースホルダを排除し、メッセージIDを持つことが必要とされています。
o The newsgroup name matching capabilities already documented in RFC 977 ("wildmats", Section 4) are clarified and extended. The new facilities (e.g., the use of commas and exclamation marks) are allowed wherever wildmats appear in the protocol.
既にRFC 977に記述能力と一致するニュースグループ名O（「wildmats」、第4章）が明らかと拡張されます。 wildmatsプロトコルに表示さどこ新しい設備（例えば、カンマと感嘆符の使用）が許可されます。
o Support for pipelining of commands (Section 3.5) is made mandatory.
Oコマンド（3.5節）のパイプラインのサポートが必須となっています。
o The principles behind response codes (Section 3.2) have been tidied up. In particular:
応答コード（セクション3.2）の原理oを片付けてきました。特に：
* the x8x response code family, formerly used for private extensions, is now reserved for authentication and privacy extensions;
*以前はプライベート拡張のために使用さx8x応答コードファミリーは、現在、認証とプライバシーの拡張のために予約されています。
* the x9x response code family, formerly intended for debugging facilities, are now reserved for private extensions;
*旧施設をデバッグするためのものx9x応答コードファミリーは、現在、民間の拡張のために予約されています。
* the 502 and 503 generic response codes (Section 3.2.1) have been redefined;
* 502と503の一般的な応答コード（セクション3.2.1）が再定義されています。
* new 401, 403, 480, 483, and 504 generic response codes have been added.
*新規401、403、480、483、及び504のジェネリック応答コードが追加されています。
o The rules for article numbering (Section 6) have been clarified (also see Section 6.1.1.2).
記事番号（第6節）明らかにされているためのルールO（また、セクション6.1.1.2を参照してください）。
o The SLAVE command (which was ill-defined) is removed from the protocol.
O（病気に定義された）SLAVEコマンドは、プロトコルから除去されます。
o Four-digit years are permitted in the NEWNEWS (Section 7.4) and NEWGROUPS (Section 7.3) commands (two-digit years are still permitted). The optional distribution parameter to these commands has been removed.
O 4桁の年がNEWNEWS（7.4節）とNEWGROUPS（7.3節）で許可されている（2桁の年は、まだ許可されている）コマンド。これらのコマンドのオプションの分布パラメータは削除されました。
o The LIST command (Section 7.6.1) is greatly extended; the original is available as LIST ACTIVE, while new variants include ACTIVE.TIMES, DISTRIB.PATS, and NEWSGROUPS. A new "m" status flag is added to the LIST ACTIVE response.
O LISTコマンド（セクション7.6.1）が大幅に延長されます。新しい亜種がACTIVE.TIMES、DISTRIB.PATS、およびニュースグループを含めながら、元のは、LIST ACTIVEとして利用可能です。新しい「M」ステータスフラグはLIST ACTIVE応答に追加されます。
o A new CAPABILITIES command (Section 5.2) allows clients to determine what facilities are supported by a server.
新しい機能のコマンド（5.2節）Oクライアントは施設がサーバによってサポートされているかを判断することができます。
o The DATE command (Section 7.1) is adopted from RFC 2980 effectively unchanged.
DATEコマンド（セクション7.1）O RFC 2980効果的に変わらないから採用されています。
o The LISTGROUP command (Section 6.1.2) is adopted from RFC 2980. An optional range argument has been added, and the 211 initial response line now has the same format as the 211 response from the GROUP command.
LISTGROUPコマンド（6.1.2）は、RFC 2980から採用されているoを任意の範囲引数が追加され、211初期応答ラインがグループコマンドから211応答と同じフォーマットを有します。
o The MODE READER command (Section 5.3) is adopted from RFC 2980 and its meaning and effects clarified.
OモードのREADERコマンド（5.3節）は、RFC 2980から採用され、その意味と効果が明らかになりました。
o The XHDR command in RFC 2980 has been formalised as the new HDR (Section 8.5) and LIST HEADERS (Section 8.6) commands.
O RFC 2980でXHDRコマンドは、新しいHDR（セクション8.5）とLISTヘッダ（8.6節）コマンドとして定式化されています。
o The XOVER command in RFC 2980 has been formalised as the new OVER (Section 8.3) and LIST OVERVIEW.FMT (Section 8.4) commands. The former can be applied to a message-id as well as to a range.
oをRFC 2980でXOVERコマンドは、新しいOVER（8.3節）とLIST OVERVIEW.FMT（8.4節）コマンドとして定式化されています。前者は、メッセージIDにならびに範囲に適用することができます。
o The concept of article metadata (Section 8.1) has been formalised, allowing the Bytes and Lines pseudo-headers to be deprecated.
O記事メタデータ（8.1節）の概念は、バイト、行疑似ヘッダは廃止されることを可能にする、形式化されています。
Client authors should note in particular that lack of support for the CAPABILITIES command is a good indication that the server does not support this specification.
クライアントの著者は、capabilitiesコマンドのサポートの欠如は、サーバーがこの仕様をサポートしていないことを良い兆候であることに特に注意してください。
Author's Address
著者のアドレス
Clive D.W. Feather THUS plc 322 Regents Park Road London N3 2QQ United Kingdom
クライヴD.W.フェザーTHUSピーエルシー322リージェンツパークRoadロンドンN3 2QQイギリス
Phone: +44 20 8495 6138 Fax: +44 870 051 9937 EMail: clive@demon.net URI: http://www.davros.org/
電話：+44 20 8495 6138ファックス：+44 870 051 9937 Eメール：clive@demon.net URI：http://www.davros.org/
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）によって提供されます。