[要約] RFC 3977は、NNTP（Network News Transfer Protocol）に関する仕様を定義しており、ニュースグループの投稿や取得などの機能を提供します。このRFCの目的は、インターネット上でのニュースグループの運用を効率的かつ信頼性の高い方法で行うためのガイドラインを提供することです。
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)
ネットワーク ニュース転送プロトコル (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.
Network News Transfer Protocol (NNTP) はインターネットで 10 年前から使用されており、現在でも (量的に) 最も人気のあるプロトコルの 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 デフォルトの文字セットは US-ASCII [ANSI1986] から UTF-8 [RFC3629] に変更されます (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 ではオプションだった、または RFC 2980 [RFC2980] から取り入れられた多くのコマンドが必須になりました。そして
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 要件の 1 つ以上を満たしていない場合、その実装は準拠していません。プロトコルのすべての MUST 要件とすべての SHOULD 要件を満たす実装は、「無条件に準拠している」と言われます。NNTP の MUST 要件をすべて満たすが、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).
楕円は、引数が ... マークの回数だけ繰り返してもよいことを示します (少なくとも 1 回は出現する必要があります)。
vertical|bar indicates a choice of two mutually exclusive arguments (exactly one must be provided).
vertical|bar は、相互に排他的な 2 つの引数の選択を示します (正確に 1 つを指定する必要があります)。
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.
コマンドまたは応答引数の名前「message-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 の文法に適合しない場合)、NNTP サーバーは(この文書で指定されていない) 何らかの解釈を加えてもよい (MAY) か、そうでない場合は構文エラーとして扱わなければなりません (MUST)。
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」、「TAB」、「LF」、「CR」、および「スペース」という用語は、それぞれオクテット %x00、%x09、%x0A、%x0D、および %x20 (つまり、これらのオクテットを指します)US-ASCII [ANSI1986] のコード、したがって UTF-8 [RFC3629] のコード)。「CRLF」または「CRLF ペア」という用語は、CR の直後に LF が続くシーケンス (つまり、%x0D.0A) を意味します。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 サーバー ホストは挨拶を送信しなければなりません (MUST)。その後、クライアント ホストとサーバー ホストは、接続が閉じるか中止されるまで、それぞれコマンドと応答を交換します。使用される接続が 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 つ以上の引数が続いてもよい (MAY)。CRLF ペアはすべてのコマンドを終了しなければなりません。複数のコマンドを同じ行に記述してはなりません。この文書の他の場所で特に断りのない限り、引数は印刷可能な US-ASCII 文字で構成する必要があります (SHOULD)。キーワードと引数は、それぞれ 1 つ以上のスペースまたはタブ文字で区切る必要があります。コマンドラインは、終端の CRLF ペアを含む 512 オクテットを超えてはなりません。引数は 497 オクテットを超えてはなりません。サーバーは、拡張機能で定義されたコマンドのこれらの制限を緩和してもよい(MAY)。
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 0000 から U 007F の範囲外の UTF-8 文字を許可する場合、実装ではバイト オーダー マーク (U FEFF、エンコード %xEF.BB.BF) を使用してはならず、Word Joiner (U 2060、エンコード %) を使用しなければなりません (MUST)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 (A-dieresis で構成された A) は 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 桁の応答コードで始まらなければなりません (MUST)。特定の有効な応答は複数行になるように定義されています。他のすべての場合、応答は 1 行に含まれます。応答の最初の行は、応答コードと終端の CRLF ペアを含む 512 オクテットを超えてはなりません。拡張機能は、それが定義するコマンドについては、より大きな最大値を指定してもよい（MAY）が、他のコマンドについては指定できません。単一行の応答は最初の行のみで構成されます。複数行の応答は、最初の行とそれに続く複数行のデータ ブロックで構成されます。
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 サーバーには、非アクティブ自動ログアウト タイマーがあってもよい(MAY)。このようなタイマーは、サーバーがクライアントからの最初のコマンドを待機する時間について、より短い制限があってもよい (MAY) 場合を除き、少なくとも 3 分間の長さである必要があります (SHOULD)。自動ログアウト タイマーをリセットするには、タイマー間隔中にクライアントからコマンドを受信するだけで十分である必要があります。同様に、複数行のデータ ブロックを送信しているクライアントから大量のデータを受信した場合 (POST または IHAVE コマンド中など)、自動ログアウト タイマーをリセットするのに十分であるべきです (SHOULD)。タイマーが期限切れになると、サーバーはクライアントに応答を送信せずに接続を閉じる必要があります (SHOULD)。
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. ブロックは 0 個以上の一連の「ライン」で構成され、それぞれが CRLF ペアで終わるオクテットのストリームです。これらの行末を除いて、ストリームにはオクテット NUL、LF、CR を含めてはなりません (MUST NOT)。
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.
3. データ ブロックの行が「終了オクテット」(「.」または %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. ブロックの行の後には、通常の方法で 1 つの終了オクテットとそれに続く CRLF ペアで構成される終了行が続いていなければなりません (MUST)。したがって、空でない限り、複数行のブロックは常に 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.
5. 複数行のブロックが解釈されるときは、「ドットの詰め込み」を元に戻さなければなりません。つまり、受信者は、終端オクテットで始まり、その後に CRLF ペア以外のオクテットが続く行において、最初の終端オクテットが無視されることを保証しなければなりません (MUST)。
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) を複数行ブロックの一部とみなしてはならない (MUST NOT)。つまり、受信者は、終了オクテットで始まり、すぐに CRLF ペアが続く行がすべて無視されるようにしなければなりません (MUST)。(空ではないブロックの終端 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.
CRLF ペア以外のオクテット NUL、LF、または CR を含む可能性のあるエンコーディング (UTF-16 や UTF-32 など) を使用するテキストは、上記の形式で確実に伝達できないことに注意してください (つまり、MUST 要件に違反します)。その上）。ただし、特に明記されていない限り、この仕様はコンテンツが UTF-8 であることを要求していないため、(同じ要件に従って) 128 の上下のオクテットを任意に混合してもよい (MAY)。
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.
この文書では、複数行ブロック内の 1 行の長さに制限を設けません。ただし、記事の形式を定義する標準によってはそうされる場合があります。
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.
引数は、数値ステータス インジケーターから、および引数同士を 1 つのスペースで区切る必要があります。すべての数値引数は基数 10 (10 進数) 形式でなければならず、先頭にゼロがあってもよい (MAY)。文字列引数には少なくとも 1 文字を含める必要があり、TAB、LF、CR、またはスペースを含めてはなりません。サーバーは、必要に応じて応答コードまたは最後の引数の後にテキストを追加してもよく、クライアントはこのテキストに基づいて決定を行ってはなりません (MUST NOT)。このようなテキストは、数値ステータスインジケーターまたは最後の引数から少なくとも 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 で与えられる) でコマンドに応答しなければなりません (MUST)。それ以外の場合、認識された各コマンドは、その説明または拡張子に具体的にリストされている応答コードの 1 つを返さなければなりません (MUST)。サーバーは、新しいコマンド、既存のコマンドの新しいバリアントまたは機能、およびサーバーの内部状態を変更するその他の方法を含む、この仕様への拡張を提供してもよい(MAY)。ただし、サーバーは追加機能を呼び出さないクライアントに対して他の応答を生成してはなりません (MUST NOT)。(したがって、この仕様に自身を制限するクライアントは、リストされている応答のみを受け取ります。)
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.
クライアントが予期しない応答を受信した場合、応答の最初の桁を使用して結果を判断すべきです(SHOULD)。たとえば、予期しない 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.
この文書で指定されていない応答コードは、指定されていないインストール固有の追加コマンドにも使用できます (MAY)。これらは、上で指定した 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.
サーバーは、状況を表す場合には、次の一般的な応答の適切な 1 つでコマンドに応答しなければなりません (MUST)。
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 を返さなければなりません (MUST)。
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 を返さなければなりません (MUST)。行を切り詰めたり分割したりして解釈してはなりません。コマンドに 2 番目のキーワードに応じたバリエーションがある場合 (LIST ACTIVE や LIST NEWSGROUPS など)、基本コマンドは実装されているが要求されたバリエーションは実装されていない場合は 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を返さなければなりません(MUST)。
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.
サーバーが現在の状態にあるときに、クライアントが指定された機能を使用することを許可されていない場合は、次の応答コードの適切な 1 つを使用しなければなりません (MUST)。
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 を参照) は、MODE READER コマンド (セクション 5.3) の使用後にこのコマンドが使用可能になることを示すためにこの応答を使用していましたが、この使用法はこの仕様に準拠していないため、使用してはなりません (MUST NOT)。使用済み。サーバーは、最初の接続 (セクション 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: この接続で機能を使用する前に、クライアントはサーバーに対して自身を認証する必要があります (つまり、クライアントの ID に関する情報を提供する必要があります)。これには、[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 を参照) でなければなりません。サーバーは、問題の機能の定義で指定されている場合を除き、この応答コードを使用してはなりません (MUST NOT)。
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 回の応答ごとに待機時間を 2 倍にする）か、関連するテキストをユーザーに提示して、再試行するかどうか、いつ行うかを決定できるようにする必要があります（SHOULD）。
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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] リーダー [S] ニュース [S] アクティブなニュースグループのリスト [S] 。[C] OVER [S] 500 不明なコマンド
Example of an unsupported variant:
サポートされていないバリアントの例:
[C] MODE POSTER [S] 501 Unknown MODE option
[C] MODE POSTER [S] 501 不明な MODE オプション
Example of a syntax error:
構文エラーの例:
[C] ARTICLE a.message.id@no.angle.brackets [S] 501 Syntax error
[C] ARTICLE 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] HEAD 53 54 55 [S] 501 引数が多すぎます
Example of a bad 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 READER [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] GROUP 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 fred flintstone [S] 290 fred のパスワードが受け入れられました [C] GROUP secret.group [S] 211 5 1 20 secret.group selected
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 Secret.グループが選択されました
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] GROUP binary.group [S] 401 XHOST この仮想ホスト上にありません [C] XHOST binary.news.example.org [S] 290 binary.news.example.org 仮想ホストが選択されました [C] GROUP binary.group [S] 211 5 1 77 バイナリ.グループが選択されました
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:
各機能行は 1 つ以上のトークンで構成されており、トークンは 1 つ以上のスペースまたはタブ文字で区切る必要があります。トークンは、1 つ以上の印刷可能な UTF-8 文字の文字列です (つまり、印刷可能な US-ASCII 文字または US-ASCII 範囲外の UTF-8 シーケンスのいずれかですが、スペースや TAB は含みません)。特に明記されていない限り、トークンでは大文字と小文字が区別されません。各機能ラインは以下で構成されます。
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.
サーバーは、機能リストが現在利用可能な機能 (拡張機能を含む) を正確に反映していることを確認しなければなりません (MUST)。機能が特定の状態のサーバーでのみ利用可能である場合 (たとえば、認証後のみ)、サーバーがその状態にあるときの機能ラベルのみをリストに含めなければなりません (MUST)。同様に、拡張機能内の一部のコマンドのみが使用可能である場合、または拡張機能の動作がサーバーの状態に応じて他の方法で変更される場合、これを機能行の異なる引数で指定しなければなりません(MUST)。
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.
バージョン この機能はすべてのサーバーによってアドバタイズされなければならず、機能リストの最初の機能でなければなりません。これは、サーバーがサポートする NNTP のバージョンを示します。少なくとも 1 つの引数が必要です。各引数は 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.
IHAVE この機能は、サーバーが IHAVE コマンドを実装していることを示します。
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 HEADERS) を実装していることを示します。
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 この機能は、サーバーが概要アクセス コマンド (OVER および LIST OVERVIEW.FMT) を実装していることを示します。サーバーが OVER コマンドのメッセージ ID 形式をサポートしている場合に限り、引数 MSGID が 1 つ必要です。
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 コマンドの少なくとも 1 つのバリアントを実装していることを示します。サーバーがサポートする 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.)
実装 この機能はサーバーによって提供される場合があります。その場合、サーバー ソフトウェア名やバージョン番号などの情報を提供するために引数を使用する必要があります (SHOULD)。クライアントは、サーバーの機能を決定するためにこの行を使用してはなりません (MUST NOT)。(サーバーは最初の挨拶でこの情報を提供することがよくありますが、クライアントはこれが当てはまるかどうかを推測する必要があります。この機能により、情報が何であるかが明確になります。)
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) であり、READER 機能を有効にするには MODE READER コマンドを使用する必要があることを示します。
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 つの新しい機能ラベルを定義しなければなりません (これは、多くの場合、これらの新しいコマンドのいずれかの名前になりますが、必ずしもそうである必要はありません)。追加の機能情報は通常、そのラベルの引数を使用して指定できますが、拡張機能では複数の機能ラベルを定義してもよい(MAY)。ただし、これは例外的な状況に限定されるべきです。
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.
拡張機能はプライベート拡張機能であるか、その機能が IANA 機能レジストリ (セクション 3.3.4 を参照) に含まれており、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").
o 拡張機能に関連付けられた新しい NNTP コマンド (登録された拡張機能に関連付けられたコマンドの名前は「X」で始まってはなりません)。
o The syntax and possible values of arguments associated with the new NNTP commands.
o 新しい NNTP コマンドに関連付けられた引数の構文と可能な値。
o The response codes and possible values of arguments for the responses of the new NNTP commands.
o 新しい NNTP コマンドの応答の応答コードと引数の可能な値。
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.
o モード切り替えサーバーでの MODE READER の使用が拡張機能とどのように対話するかについての説明。
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.
o セクション9.9で説明されている正式な構文。
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」で始まらなければなりません。サーバーは、プライベート拡張機能の一部として追加のキーワード (新しいコマンドおよび既存のコマンドの新しいバリアント) を提供してもよい(MAY)。将来登録される拡張機能との衝突のリスクを避けるために、これらのキーワードは「X」で始まるべきです(SHOULD)。
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.
サーバーが登録された拡張機能によって定義された機能をアドバタイズする場合、仕様に完全に準拠するように拡張機能を実装しなければなりません (たとえば、拡張機能で必須として説明されているすべてのコマンドを実装しなければなりません)。指定どおりに拡張機能を実装していない場合、その拡張機能をその登録名で機能リストにリストしてはなりません (MUST NOT)。その場合、拡張機能の一部を実装したり、拡張機能のコマンドを別の意味で実装したりするプライベート拡張機能 (リストされていない、または別の名前でリストされている) を提供してもよいが、提供すべきではありません (SHOULD NOT)。
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 コマンド、または登録された拡張機能に記載されているコマンドに、異なる応答コードを送信してはなりません (MUST NOT)。
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 ラベルがサーバーから返される機能リストに含まれている場合、サーバーはそのバンドル内のすべてのコマンドをサポートしなければなりません(MUST)。
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 ラベルが含まれていない場合、サーバーはコマンドをまったくサポートしないか、一部のコマンドをサポートしてもよい(MAY)が、それらのすべてをサポートすべきではない(SHOULD NOT)。一般に、クライアントは、どのコマンドがサポートされているかを、試してみることなしに判断することができません。
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 汎用応答コード (または、基本コマンドが認識される 2 番目のキーワードに応じたコマンドのバリアントの場合は 501 汎用応答コード) を生成しなければなりません (MUST)。それ以外の場合、コマンドは指定どおりに完全に実装されなければなりません。サーバーは、この仕様のコマンドを部分的にのみ実装してはなりません (MUST NOT)。(クライアント作成者は、この仕様に準拠していない一部のサーバーは、実装されていない一部のコマンドに対して 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.
注: 一部のコマンドでは、最初に他のコマンドを使用する必要がある場合があります。前者のコマンドが実装されているが後者が実装されていない場合でも、前者は関連する特定の応答コードを生成しなければなりません(MUST)。たとえば、ARTICLE (セクション 6.2.1) が実装されているが、GROUP (セクション 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 つの異なる方法で使用されます。最初の用途は「読み取り」です。クライアントは、即時または後でユーザーに提示するためにサーバーによって維持されている大規模なストアから記事を取得し、そのユーザーが作成した記事をサーバーに送り返します (「投稿」と呼ばれるアクション)。保存され、他の店舗やユーザーに配布されます。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 コマンドは転送用に設計されており、READER 機能で示されるコマンドはクライアントの読み取り用に設計されています。
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 機能のいずれかまたは両方を一度アドバタイズすると、セッション全体にわたってそれらをアドバタイズし続けなければなりません (MUST)。
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 を使用する必要があります (SHOULD)。
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.
ただし、クライアントが CAPABILITIES 以外のコマンドを使用した後、サーバーは MODE-READER 機能のアドバタイズを停止してもよい(MAY)。
o Reading mode, after a successful MODE READER command (see Section 5.3).
o MODE READER コマンドが成功した後の読み取りモード (セクション 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 機能をアドバタイズしていたとしても、IHAVE 機能をアドバタイズしてはなりません (MAY)。
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 コマンドを発行する必要があります (SHOULD)。サーバーが CAPABILITIES をサポートしていない (したがって、この仕様に準拠していない) 場合、クライアントは次のヒューリスティックを使用してもよい(MAY)。
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 コマンドを使用する必要があります (SHOULD)。
o Otherwise, it SHOULD NOT use the MODE READER command.
o それ以外の場合は、MODE READER コマンドを使用すべきではありません (SHOULD NOT)。
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 つ以上のコマンドが無視されるか誤って解釈され、クライアントが各コマンドに対する間違った応答を照合することになるため、パイプライン処理が影響を受けます。パイプラインには大きな利点があるだけでなく、サーバーが上記の方法で動作することが合理的または一般的な状況でもあるため、このドキュメントではクライアントとサーバーの両方に特定の要件を課します。
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.
特に明記されていない限り、クライアントはパイプラインを使用してもよい(MAY)。つまり、前のコマンドに対する応答を受信する前にコマンドを送信する可能性があります。サーバーはパイプラインを許可しなければならず、コマンドの後に受信したテキストを破棄してはなりません。パイプラインが使用されているかどうかに関係なく、サーバーは送信された順序でコマンドを処理しなければなりません。
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 を受信するまで、次のコマンドを送信してはなりません (MUST NOT)。サーバーは、コマンドの後、応答の終わりの 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 を受信するまで、コマンドを送信してはなりません (MUST NOT)。
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 その他のテスト [C] STAT [C] NEXT [S] 211 1234 3000234 3002322 その他のテスト [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 は、クライアントとサーバー間で記事を転送することを目的としています。この仕様の目的上、アーティクルはこのセクションのルールに準拠する必要があり、クライアントとサーバーは、準拠する相手から受信したアーティクルを正しく処理しなければなりません (MUST)。この要件は、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 つの部分で構成されます。これらは 1 つの空行、つまり 2 つの連続する CRLF ペアによって区切られます (空行が複数ある場合、2 行目以降は本文の一部になります)。NNTP の一般要件を満たすために、アーティクルにはオクテット NUL を含めてはならず、CRLF ペアの一部以外のオクテット LF および CR を含めてはならず、CRLF ペアで終了しなければなりません (MUST)。この仕様は本文にそれ以上の制限を課しません。特に、空であってもよい。
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.
記事のヘッダーは 1 つ以上のヘッダー行で構成されます。各ヘッダー行は、ヘッダー名、コロン、スペース、ヘッダー内容、CRLF の順で構成されます。名前は、コロンを除く 1 つ以上の印刷可能な US-ASCII 文字で構成され、この仕様の目的上、大文字と小文字は区別されません。同じ名前のヘッダー行が複数存在する場合があります。コンテンツには CRLF を含めてはなりません。空でも構いません。ヘッダーは「折りたたまれる」場合があります。つまり、CRLF ペアは行内の TAB またはスペースの前に配置できます。ヘッダー行の 2 つの CRLF ペアの間には、さらに他のオクテットが存在しなければなりません (MUST)。(折りたたみとは、表示または送信時にヘッダー行が複数の行を占めることを意味します。それでも、「a」ヘッダー行と呼ばれます。) 折りたたみの有無は、ヘッダー行の意味に影響しません。つまり、フォールディングによって導入された CRLF ペアはヘッダー コンテンツの一部とはみなされません。ヘッダー行はヘッダー名に続くコロンの後のスペースの前で折り返されてはならず、CRLF ペアの間に %x09 または %x20 以外の少なくとも 1 つのオクテットを含めるべきです (SHOULD)。ただし、この要件を満たさないアーティクルを他の場所から受け取った場合、クライアントとサーバーは、それを再折り畳みせずに相互に転送してもよい(MAY)。
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 である必要があります。ただし、実装が他の方法で 128 から 255 の範囲のオクテットを使用するアーティクルを他の場所から受け取った場合、それを変更せずにクライアントまたはサーバーに渡してもよい(MAY)。したがって、実装はそのようなヘッダーとそこから派生したデータ(例えば、OVERコマンドからの応答、セクション8.3)を受信できるように準備しなければならず(MUST)、それらが常にUTF-8であると仮定してはなりません(MUST NOT)。使用されるエンコーディングの識別を含む、これらのヘッダーの外部処理は、このドキュメントの範囲外です。
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 message-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 message-id には、印刷可能な US-ASCII 文字以外のオクテットを含めてはなりません (MUST NOT)。
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 を決定する方法がない場合は、メッセージ ID を合成しなければなりません (この仕様では、結果としてアーティクルが変更される必要はありません)。付録 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 形式は、Rich Salz によって最初に開発されたバージョン [SALZ1992] に基づいています。このバージョンは、ファイル名を明確にするために UNIX の「find」コマンドで使用される形式から派生したものです。これは、UNIX シェルがファイル名を照合するのと同じ方法でパターンを照合するための統一メカニズムを提供するために開発されました。
A wildmat is described by the following ABNF [RFC4234] syntax, which is an extract of that in Section 9.8.
ワイルドマットは、セクション 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 = "*" / "?"
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.
注: 文字「,」、「\」、「[」、「]」はワイルドマットでは使用できませんが、* と ?は常にワイルドカードです。これらの文字はニュースグループ名に使用できず、ワイルドマットの現在の唯一の使用方法であるため、これは問題にはなりません。バックスラッシュは通常、文字の特別な意味を抑制するために使用されますが、括弧はセットを導入するために使用されます。ただし、これらの使用法は普遍的ではなく、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-pattern> が文字列と照合され、一致する右端のパターンが特定されます。<wildmat-pattern> の前に「!」がない場合、ワイルドマット全体が一致します。先頭に「!」が付いている場合、または <wildmat-pattern> が一致しない場合は、ワイルドマット全体が一致しません。
For example, consider the wildmat "a*,!*b,*c*":
たとえば、ワイルドマット「a*,!*b,*c*」について考えてみましょう。
o The string "aaa" matches because the rightmost match is with "a*".
o 右端の一致は「a*」であるため、文字列「aaa」は一致します。
o The string "abb" does not match because the rightmost match is with "*b".
o 文字列「abb」は、右端の一致が「*b」であるため、一致しません。
o The string "ccb" matches because the rightmost match is with "*c*".
o 右端の一致が「*c*」であるため、文字列「ccb」は一致します。
o The string "xxx" does not match because no <wildmat-pattern> matches.
o <wildmat-pattern> が一致しないため、文字列 "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-pattern> は、文字列をコンポーネントに分割でき、それぞれのコンポーネントがパターン内の対応する <wildmat-item> と一致する場合、文字列と一致します。一致は同じ順序である必要があり、文字列全体が一致に使用される必要があります。パターンは「固定」されています。つまり、文字列の最初と最後の文字は、それぞれ最初と最後の項目に一致する必要があります (その項目がゼロ文字に一致するアスタリスクでない限り)。
A <wildmat-exact> matches the same character (which may be more than one octet in UTF-8).
<wildmat-exact> は、同じ文字 (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.
「*」は 0 個以上の文字に一致します。空の文字列と一致することはできますが、文字境界に揃えられていない 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 サーバーまたは拡張機能は、セクション 4.1 の要件を満たすすべてのワイルドマットがセクション 4.2 によって割り当てられた意味を持っているという条件で、ワイルドマットの構文またはセマンティクスを拡張してもよい(MAY)。このドキュメントの将来の版では、ワイルドマットも拡張される可能性があります。
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
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] 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 応答の後、サーバーは直ちに接続を閉じなければなりません (MUST)。
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.
サーバーへの最初の接続時にクライアントから提示されるコマンドはありません。サーバーは、クライアントへの挨拶として適切な応答コードを提示しなければなりません (MUST)。この応答は、サービスが利用可能かどうか、およびクライアントが投稿を許可されているかどうかをクライアントに通知します。
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 グリーティング コードを提示しなければなりません (MUST)。サーバーがクライアントからのさらなるコマンドを受け入れるが、クライアントが POST コマンドを使用して記事を投稿する権限を持たない場合、サーバーは 201 グリーティング コードを提示しなければなりません (MUST)。
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) を使用する必要があります (SHOULD)。
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] QUIT [S] 205 NNTP サービス正常終了 [サーバーが接続を切断します。]
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] QUIT [S] 205 NNTP サービス正常終了 [サーバーが接続を終了します。]
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]
構文 CAPABILITIES [キーワード]
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 応答コードに続く複数行のデータ ブロックとして返されます。各機能は、個別の機能行で説明されます。サーバーは、たとえ異なる引数であっても、応答内に同じ機能を 2 回リストしてはなりません (MUST NOT)。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 クライアントは、このコマンドの結果をキャッシュしてもよい (MAY) が、このセッションの初期のものか以前のセッションのものかに関係なく、キャッシュされた結果の正確さに依存してはならず (MUST NOT)、キャッシュされたステータスが古くても適切に対処しなければならず (MUST)、すべきである (SHOULD)結果をキャッシュする場合) は、キャッシュされた情報を強制的に更新する方法を提供します。さらに、クライアントは、セキュリティ、プライバシー、および認証拡張機能に関連して、キャッシュされた結果を使用してはなりません (MUST NOT)。このトピックの詳細については、セクション 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.
キーワード引数はこの仕様では使用されません。この仕様の拡張または改訂に、CAPABILITIES コマンドを 2 回使用する必要なく (1 回目は追加機能が利用可能かどうかを確認し、2 回目は追加機能を使用するために)、このコマンドの追加機能を含めることができるようにするために提供されています。サーバーが引数を認識しない場合（それがキーワードである場合）、引数が省略されたかのように 101 応答コードで応答しなければなりません（MUST）。サーバーが認識できる引数が指定された場合、サーバーは 101 応答コードを使用してもよいし、他の応答コード (その機能の仕様で定義される) を使用してもよいです。引数がキーワードでない場合は、汎用応答コード 501 を返さなければなりません (MUST)。サーバーは、CAPABILITIES コマンドに対して他の応答コードを生成してはなりません (MUST NOT)。
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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] リーダー [S] アクティブなニュースグループのリスト [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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] リーダー [S] IHAVE [S] POST [S] NEWNEWS [S] アクティブなニュースグループのリスト ACTIVE.TIMES OVERVIEW.FMT [S] 実装 INN 4.22004-12-25 [S] OVER MSGID [S] ストリーミング [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] 機能 [S] 101 機能リスト: [S] バージョン 2 3 [S] リーダー [S] アクティブなニュースグループのリスト [S] 。
Example of a client attempting to use a feature of the CAPABILITIES command that the server does not support:
サーバーがサポートしていない CAPABILITIES コマンドの機能をクライアントが使用しようとしている例:
[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] バージョン 2 [S] READER [S] IHAVE [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT HEADERS [S] OVER MSGID [S] HDR [S] NEWNEWS [S]] 。
Indicating capability: MODE-READER
表示機能: MODE-READER
This command MUST NOT be pipelined.
このコマンドはパイプライン化してはなりません。
Syntax MODE READER
構文モードリーダー
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 応答の後、サーバーは直ちに接続を閉じなければなりません (MUST)。
The MODE READER command instructs a mode-switching server to switch modes, as described in Section 3.4.2.
MODE READER コマンドは、セクション 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 応答を返さなければなりません (MUST)。応答は最初の挨拶中に提示されたものと同じである必要はないことに注意してください。クライアントは、セッション中、またはセキュリティまたはプライバシー コマンドの発行後に MODE READER を複数回発行してはなりません (MUST NOT)。MODE READER コマンドが発行されると、サーバーはモードを切り替える前に、最初の接続直後の状態にリセットしてもよい(MAY)。
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 READER 機能をアドバタイズする場合は、最初のグリーティングと同じ意味の 200 または 201 応答を返さなければなりません。この場合、コマンドはサーバーの状態にいかなる形でも影響を与えてはなりません。
o If it does not advertise the READER capability, it MUST return a 502 response and then immediately close the connection.
o READER 機能をアドバタイズしない場合は、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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] IHAVE [S] 。[C] MODE READER [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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] リーダー [S] アクティブなニュースグループのリスト [S] 。[C] MODE READER [S] 200 リーダーモード、投稿許可 [C] IHAVE <i.am.an.article.you.have@example.com> [S] 500 許可が拒否されました [C] GROUP misc.test [S]] 211 1234 3000234 3002322 その他のテスト
Note that in both of these situations, the client SHOULD NOT use MODE READER.
これらのどちらの状況でも、クライアントは MODE READER を使用すべきではないことに注意してください。
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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] IHAVE [S] MODE-READER [S] 。[C] MODE READER [S] 200 リーダーモード、投稿許可 [C] CAPABILITIES [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 READER [S] 201 NNTP Service Ready、投稿禁止
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 コマンドを承認し、クライアントへの接続を閉じなければなりません (MUST)。これは、クライアントが 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.
クライアントが単純に切断した場合 (または接続がタイムアウトまたはその他の障害が発生した場合)、サーバーはクライアントへのサービスの試みを適切に停止し、必要に応じてクライアント側から切断しなければなりません (MUST)。
The server MUST NOT generate any response code to the QUIT command other than 205 or, if any arguments are provided, 501.
サーバーは、QUIT コマンドに対して 205 または引数が指定されている場合は 501 以外の応答コードを生成してはなりません (MUST NOT)。
[C] QUIT [S] 205 closing connection [Server closes connection.]
[C] QUIT [S] 205 接続を閉じます [サーバーは接続を閉じます。]
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 であり、グローバルに一意です。2 番目のタイプのキーは、ニュースグループ名とそのニュースグループ内の記事番号で構成されます。特定のサーバー上では、ニュースグループ内に特定の番号を持つ記事は 1 つだけ存在しなければならず、同じニュースグループ内で記事に 2 つの異なる番号を付けてはなりません。記事は複数のニュースグループにクロス投稿できるため、同じサーバー上の同じ記事を指す複数のキーが存在する可能性があります。これらの番号はニュースグループごとに異なる場合があります。ただし、このタイプのキーはグローバルに一意である必要はないため、同じキーが異なるサーバー上の異なるアーティクルを参照しても構いません。(「グループ」と「ニュースグループ」という用語は同等であることに注意してください。)
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.
キーの最後のタイプは到着タイムスタンプで、記事がサーバーに到着した時間を示します。サーバーは、記事番号が到着タイムスタンプの順に発行されることを保証しなければなりません。つまり、後で到着する記事は、先に到着する記事よりも高い番号を持たなければなりません。サーバーは、各新しいアーティクルに、次に連続する未使用の番号を割り当てるべきです(SHOULD)。
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 桁を超える数字を使用してはなりません。場合によっては、特別な状況を示すために値 0 が記事番号を置き換えます。
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
パラメータ グループ ニュースグループの名前 番号 グループ内の推定記事数 low 報告された最低水準点 high 報告された最高水準点
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 つ減り、推定記事数は 0 になります。サーバーは空のグループを表示するためにこのメソッドを使用すべきです(SHOULD)。最高水準点が最低水準点を下回る可能性があるのはこのときだけです。
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 新しい記事は、報告された最高水準点を超える記事番号で追加される場合があります。(最も高い番号を持った記事が削除され、それに応じて最高水準点が調整された場合、次の新しい記事には、報告された最高水準点より 1 つ大きい番号が付けられることはありません。)
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 つの数値がすべて 0 の場合を除き、同じクライアントまたは別のクライアントによって同じニュースグループに対する後続の GROUP コマンドが発行されるときは常に、応答で報告される最低水準点は、このセッションにおけるそのニュースグループに対する以前の応答、およびこれまでにクライアントに送信されたそのニュースグループに対する以前の応答以上である必要があります (SHOULD)。後者の条件が満たされない場合は、一時的なものである必要があります (SHOULD)。クライアントは、ロー ウォーター マークを利用して、番号が低い記事に関する記憶されているすべての情報を削除できます。これは、これらの記事が再発することがないためです。これには、最高水準点が最低水準点より 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 を参照) を使用し、成功した応答を受信しなければなりません (MUST)。
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] グループ その他のテスト [S] 211 1234 3000234 3002322 その他のテスト
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] GROUP 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] 211 0 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 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] 211 0 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 その他.test [S] 211 1234 234 567 その他.test [C] STAT 444 [S] 223 444 <123456@example.net> を取得 [C] GROUP その他.test [S] 211 1234 234 567 その他.test [C] STAT [S] 223 234 <異なる@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]
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
パラメータ group ニュースグループの名前 range レポートする記事の範囲 番号 グループ内の推定記事数 low 報告された最低水準点 high 報告された最高水準点
[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 つの番号が含まれており、番号順に並んでいます。選択した時点でグループ内に存在する記事が正確にリストされます (したがって、空のグループは空のリストを生成します)。オプションの range 引数が指定されている場合、範囲内の記事のみがリストに含まれます (したがって、グループが空でない場合でも、リストは空であっても構いません)。
The range argument may be any of the following:
range 引数は次のいずれかになります。
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.
最後のケースでは、2 番目の数値が最初の数値より小さい場合、範囲には記事が含まれません。範囲を省略すると、範囲 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.
group 引数がオプションであること、range 引数を指定できること、および 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.
range 引数はこの仕様の新機能であり、CAPABILITIES をサポートしていない (したがってこの仕様に準拠していない) サーバーはそれをサポートしない可能性が高いことに注意してください。
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 miss.test [S] 211 2000 3000234 3002322 miss.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 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 その他のテスト [S] 211 2000 3000234 3002322 その他のテスト [C] LISTGROUP [S] 211 2000 3000234 3002322 その他のテストのリストは次のとおりです [S] 3000234 [S] 3000237 [S] 3000238 [S] 3 000239 [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 miss.test 3000238-3000248 [S] 211 2000 3000234 3002322 miss.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 miss.test 12345678- [S] 211 2000 3000234 3002322 miss.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 miss.test 9999-111 [S] 211 2000 3000234 3002322 miss.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
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 応答を返さなければなりません (MUST)。現在の記事番号が無効な場合は、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 その他のテスト [S] 211 1234 3000234 3002322 その他のテスト [C] 次の [S] 223 3000237 <668929@example.org> が取得されました [C] 最後 [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 その他.test [S] 211 1234 3000234 3002322 その他.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] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] LAST [S] 420 現在の記事が選択されていません
Indicating capability: READER
機能の表示: READER
Syntax 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
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 応答を返さなければなりません (MUST)。他のすべての点では (もちろん 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] GROUP その他.test [S] 211 1234 3000234 3002322 その他.test [C] NEXT [S] 223 3000237 <668929@example.org> を取得しました
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:
現在の記事番号がグループ内の最後の記事の番号である場合に、NEXT コマンドを使用して記事を取得しようとする例:
[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] GROUP example.empty.newsgroup [S] 211 0 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 つのコマンドについては相違点について説明します。セクション 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 番号 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 記事が続きます (複数行) 430 そのメッセージ ID を持つ記事はありません
Second form (article number specified)
220 n message-id Article follows (multi-line)
412 No newsgroup selected
423 No article with that number
Third form (current article number used)
220 n message-id Article follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
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).
現在選択されているニュースグループがあり、そのグループに記事が存在する場合を除き、応答では記事番号をゼロに置き換えなければなりません(MUST)。その場合、サーバーはそのグループ内の記事の番号を使用してもよい(MAY)。(サーバーは、その記事が現在選択されているニュースグループに含まれているかどうか、また、含まれている場合にはその記事番号が何であるかを判断する必要はありません。クライアントは、常にゼロが指定されるように準備しなければなりません。) サーバーは、次の場合を除き、記事番号を提供してはなりません(MUST NOT)。このコマンドの直後に続く 2 番目の ARTICLE コマンドでその番号を使用すると、同じ記事が返されます。このような状況でサーバーが記事番号を返すことを選択したとしても、一貫してそうする必要はありません。そのようなコマンドに対しては 0 を返してもよい (STAT の例、セクション 6.2.4.3 も参照)。
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.
2 番目の形式では、商品番号を指定します。現在選択されているニュースグループにその番号の記事がある場合、サーバーは現在の記事番号をその番号に設定しなければなりません(MUST)。
In the third form, the article indicated by the current article number in the currently selected newsgroup is used.
3 番目の形式では、現在選択されているニュースグループ内の現在の記事番号で示される記事が使用されます。
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.
以前に有効だった記事番号は、記事が削除された場合には無効になる可能性があることに注意してください。以前に無効だった記事番号は、記事が復元された場合に有効になる場合がありますが、この記事番号は、そのグループについて報告された最低水準点以上でなければなりません (MUST)。
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.
サーバーは、このコマンドの結果として現在選択されているニュースグループを変更してはなりません (MUST NOT)。サーバーは、記事番号引数が指定され、記事が存在する場合を除き、現在の記事番号を変更してはなりません (MUST NOT)。特に、応答が失敗した後にそれを変更してはなりません。
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 応答を返さなければなりません (MUST)。引数が数値であるか省略されており、現在選択されているニュースグループが無効な場合は、412 応答を返さなければなりません (MUST)。引数が数値であり、その記事が現在選択されているニュースグループに存在しない場合は、423 応答を返さなければなりません (MUST)。引数が省略され、現在の記事番号が無効な場合は、420 応答を返さなければなりません (MUST)。
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 その他.test [S] 211 1234 3000234 3002322 その他.test [C] ARTICLE [S] 220 3000234 <45223423@example.com> [S] パス: pathost!demo!whitehouse!not-for-mail [S] 送信者: "デモ ユーザー" <nobody@example.net> [S] ニュースグループ: misc.test [S] 件名: 私は単なるテスト記事です [S] 日付: 6 Oct 1998 04:38:40 -0500 [S] 組織: An Example Net、Uncertain、Texas [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] ARTICLE <45223423@example.com> [S] 220 0 <45223423@example.com> [S] パス: pathost!demo!whitehouse!not-for-mail [S] From: "デモ ユーザー" <nobody@example.net> [S] ニュースグループ: misc.test [S] 件名: 私は単なるテスト記事です [S] 日付: 6 Oct 1998 04:38:40 -0500 [S] 組織: An Example Net, Uncertain,テキサス [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] ARTICLE <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 その他.test [S] 211 1234 3000234 3002322 news.groups [C] ARTICLE 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] ARTICLE 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] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] ARTICLE [S] 420 現在の記事が選択されていません
This command is mandatory.
このコマンドは必須です。
Syntax HEAD message-id HEAD number HEAD
構文 HEAD メッセージ ID HEAD 番号 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
Third form (current article number used)
221 n message-id Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
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 コマンドは、アーティクルが存在する場合、応答コードが 220 ではなく 221 であり、ヘッダーのみが表示される点を除き、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 その他.test [S] 211 1234 3000234 3002322 その他.test [C] HEAD [S] 221 3000234 <45223423@example.com> [S] パス: pathost!demo!whitehouse!not-for-mail [S] 送信者: "デモ ユーザー" <nobody@example.net> [S] ニュースグループ: misc.test [S] 件名: 私は単なるテスト記事です [S] 日付: 6 Oct 1998 04:38:40 -0500 [S] 組織: An Example Net、Uncertain、Texas [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!demo!whitehouse!not-for-mail [S] From: "デモ ユーザー" <nobody@example.net> [S] ニュースグループ: misc.test [S] 件名: 私は単なるテスト記事です [S] 日付: 6 Oct 1998 04:38:40 -0500 [S] 組織: An Example Net, Uncertain,テキサス [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 その他.test [S] 211 1234 3000234 3002322 その他.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] GROUP example.empty.newsgroup [S] 211 0 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 本文が続きます (複数行) 430 そのメッセージ ID を持つ記事はありません
Second form (article number specified)
222 n message-id Body follows (multi-line)
412 No newsgroup selected
423 No article with that number
Third form (current article number used)
222 n message-id Body follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
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 コマンドは、アーティクルが存在する場合、応答コードが 220 ではなく 222 で、本文のみが表示される点を除いて、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 その他のテスト [S] 211 1234 3000234 3002322 その他のテスト [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] GROUP example.empty.newsgroup [S] 211 0 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
Third form (current article number used)
223 n message-id Article exists
412 No newsgroup selected
420 Current article number is invalid
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 コマンドは、アーティクルが存在する場合、それがクライアントに提示されず、応答コードが 220 ではなく 223 になることを除いて、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.
このコマンドを使用すると、クライアントは任意の量のテキストを処理することなく、記事が存在するかどうか、また 2 番目と 3 番目の形式ではそのメッセージ 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 その他のテスト [S] 211 1234 3000234 3002322 その他のテスト [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>
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 その他のテスト [S] 211 1234 3000234 3002322 その他のテスト [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] GROUP example.empty.newsgroup [S] 211 0 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>
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 を確立します。2 番目と 3 番目は、メッセージ ID が指定されたときにサーバーが記事番号を与えることができるが、与える必要はないことを示しています。4 番目の STAT コマンドは、記事が現在選択されているニュースグループにない場合はゼロを指定する必要があることを示しています。5 番目は、番号が指定されている場合は、現在選択されているニュースグループに関連する番号でなければならないことを示しています。最後のものは、メッセージ 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 を使用した他のニュース サーバーからの記事の転送の 2 つの方法のいずれかで行われます。
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 を参照)。したがって、行上の 1 つのドット (「.」) はテキストの終わりを示し、元のテキストでドットで始まる行は送信時にそのドットが 2 倍になります。
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.
クライアントによる終了シーケンスの提示に続いて、サーバーは記事転送の成功または失敗を示す応答を返さなければなりません(MUST)。応答コード 340 と 440 は POST コマンドに対する直接応答で使用され、240 と 441 は記事の送信後に返されることに注意してください。
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 の応答は、予期しないサーバーエラーがなければ、投稿された記事がサーバー上で利用可能になる、および/または必要に応じてさらなる処理後に他のサーバーに転送されることを示すべきである(SHOULD)。言い換えれば、サーバーが望まない記事は、受け入れられてから黙って破棄されるのではなく、441 応答で拒否されるべきです(SHOULD)。ただし、クライアントは、サーバーから肯定的な応答を受信しない限り、アーティクルが正常に転送されたと想定すべきではありません (SHOULD NOT)。また、(たとえば、STAT コマンドを使用して) 明示的に確認することなく、アーティクルが他のクライアントに利用可能になっていると想定すべきではありません (SHOULD NOT)。
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
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
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 Service Ready、投稿禁止 [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 転送する記事を送信 435 記事は不要です 436 転送できません。あとでもう一度試してみてください
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 レスポンスを返さなければなりません (MUST)。サーバーが記事を必要としない場合 (たとえば、サーバーがすでに記事のコピーを持っている場合)、記事が必要ではないことを示す 435 応答を返さなければなりません (MUST)。最後に、記事がすぐに必要ではないが、クライアントが可能であれば後で再試行する必要がある場合 (たとえば、別のクライアントが同じ記事をサーバーに送信中の場合)、436 応答を返さなければなりません(MUST)。
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 を参照)。したがって、行上の 1 つのドット (「.」) はテキストの終わりを示し、元のテキストでドットで始まる行は送信時にそのドットが 2 倍になります。サーバーは、記事が正常に転送されたことを示す 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 応答と同じように扱われる必要があります（SHOULD）。
Because some news server software may not immediately be able to determine whether an article is suitable for posting or forwarding, an NNTP server MAY acknowledge the successful transfer of the article (with a 235 response) but later silently discard it.
一部のニュース サーバー ソフトウェアは、記事が投稿または転送に適しているかどうかをすぐに判断できない場合があるため、NNTP サーバーは記事の転送が成功したことを (235 応答で) 確認してもよいが、後で黙って破棄してもよい(MAY)。
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
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 は記事ヘッダーのメッセージ 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
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
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
パラメータ yyyymmddhhmmss サーバー上の現在の UTC 日付と時刻
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 またはその他の方法で、システム クロックを可能な限り正確に保つ必要があります (SHOULD)。
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 応答を返さなければなりません (MUST)。この日付と時刻は協定世界時です。
[C] DATE [S] 111 19990623135624
[C] 日付 [S] 111 19990623135624
This command is mandatory.
このコマンドは必須です。
Syntax 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] .
[C] HELP [S] 100 ヘルプ テキストが続きます [S] これはヘルプ テキストです。このテストには特定の [S] フォーマット要件はありませんが、[S] 有効なコマンドをリストし、[S] それらのコマンドの動作の簡単な定義を与えるのが通例です。[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
パラメータ date yymmdd または yyyymmdd 形式の日付 time hhmmss 形式の時刻
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.
日付は [xx]yymmdd の形式で 6 桁または 8 桁で指定します。xx は年の最初の 2 桁 (19 ～ 99)、yy は年の最後の 2 桁 (00 ～ 99)、mm は年の最初の 2 桁 (19 ～ 99) です。月 (01 ～ 12)、dd は日 (01 ～ 31) です。クライアントは年の 4 桁すべてを指定する必要があります (SHOULD)。年の最初の 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.
時刻は、hhmmss 形式の 6 桁で指定します。hh は 24 時間制の時間 (00 ～ 23)、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」引数を含めて) すべてのクエリを作成する必要があります (SHOULD)。
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] NEWGROUPS 19990624 000000 GMT [S] 231 新しいニュースグループのリストは [S] 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] NEWGROUPS 19990624 000000 GMT [S] 231 新しいニュースグループのリストは [S] に続きます。
Indicating capability: NEWNEWS
能力を示す：NEWNEWS
Syntax NEWNEWS wildmat date time [GMT]
構文 NEWNEWS ワイルドマット日付時刻 [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
パラメータ wildmat 対象のニュースグループ date yymmdd または yyyymmdd 形式の日付 time hhmmss 形式の時刻
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.
このコマンドは、指定された日時以降に、名前がワイルドマットに一致するニュースグループ内の、サーバー上で投稿または受信された記事のメッセージ ID のリストを返します。1 つのメッセージ ID が各行に送信されます。応答の順序には特別な意味はなく、同じセッション内の応答ごとに異なる場合があります。メッセージ ID は複数回出現してもよい (MAY)。存在する場合は、1 回だけ出現したのと同じ意味になります。
Date and time are in the same format as the NEWGROUPS command (see Section 7.3).
日付と時刻は NEWGROUPS コマンドと同じ形式です (セクション 7.3 を参照)。
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 news.*,sci.* 19990624 000000 GMT [S] 230 メッセージ ID 別の新しい記事のリストは次のとおりです [S] <i.am.a.new.article@example.com> [S] <i.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] 230 メッセージ ID 別の新しい記事のリストが [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.
最初のセッション: DATE コマンドを発行し、結果を記録します。以前に選択したタイムスタンプを使用して 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.
後続のセッション: DATE コマンドを発行し、結果を一時ストレージに保持します。前のセッションから保存されたタイムスタンプを使用して 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 で使用する前にタイムスタンプを 2 ～ 3 分戻すように調整することができます。
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 local.chat 20001231 235959 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):
2 番目のセッション (クライアントは以前に返されたタイムスタンプから 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 local.chat 20010203 111933 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.
LIST ファミリのコマンドはすべて、複数行の情報を返します。一般に、セッション中に変更されないことが予想されます。多くの場合、情報はニュースグループに関連しており、その場合、応答はニュースグループごとに 1 行になり、情報が返されるグループを制限するためにワイルドマットを提供してもよい(MAY)。
The set of available keywords (including those provided by extensions) is given in the capability list with capability label LIST.
使用可能なキーワードのセット (拡張機能によって提供されるキーワードを含む) は、機能ラベル LIST が付いた機能リストに示されます。
Indicating capability: LIST
能力の表示：LIST
Syntax LIST [keyword [wildmat|argument]]
構文 LIST [キーワード [ワイルドマット|引数]]
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.
[1] キーワードが指定されない場合、デフォルトは ACTIVE になります。
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 コマンドを使用すると、サーバーはクライアントに情報のブロックを提供できます。この情報はグローバルなものである場合もあれば、ニュースグループに関連している場合もあります。後者の場合、情報はすべてのグループに対して返されることも、ワイルドマットに一致するグループに対してのみ返されることもあります。情報の各ブロックは異なるキーワードで表されます。このコマンドは、キーワードで識別された特定の情報を返します。
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 応答コードを返さなければなりません (MUST)。キーワードが認識されたが、サーバーが情報を保持していない場合は、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 コマンドが発行されたかどうかによって影響を受けてはなりません (MUST NOT)。たとえば、そうでなければ利用できないグループを利用可能にしてはなりません。
Example of LIST with the ACTIVE keyword:
ACTIVE キーワードを使用した LIST の例:
[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] 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] 。
Example of LIST with no keyword:
キーワードのない LIST の例:
[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] comp.risks 442001 441099 m [S] alt.rfc-writers.recovery 4 1 y [S] tx.natives。リカバリ 89 56 y [S] tx.natives.recovery.d 11 9 n [S] 。
The output is identical to that of the previous example.
出力は前の例と同じです。
Example of LIST on a newsgroup-based keyword with and without wildmat:
ワイルドマットを使用した場合と使用しない場合のニュースグループ ベースのキーワードの LIST の例:
[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 ACTIVE.TIMES [S] 215 情報が続きます [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 情報が続きます [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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] リーダー [S] アクティブなニュースグループのリスト ACTIVE.TIMES XTRA.DATA [S] 。[C] LIST XTRA.DATA [S] 503 データ項目が格納されていません
Example of LIST where the keyword is not recognised:
キーワードが認識されない LIST の例:
[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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] リーダー [S] アクティブなニュースグループのリスト ACTIVE.TIMES XTRA.DATA [S] 。[C] LIST DISTRIB.PATS [S] 501 構文エラー
This specification defines the following LIST keywords:
この仕様では、次の LIST キーワードが定義されています。
+--------------+---------------+------------------------------------+
| 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.
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:
LIST ACTIVE は、有効なニュースグループと関連情報のリストを返します。ワイルドマットが指定されていない場合、サーバーは、クライアントが 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:
通常、ステータス フィールドは次のいずれかになります。
"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.
サーバーは、これらの意味が必要な場合にこれらの値を使用すべきであり、他の意味で使用してはなりません。ステータスには他の値が存在する可能性があります。これらの他の値の定義とそれらが返される状況は、拡張機能で指定することも、サーバーに対してプライベートにすることもできます。クライアントは、認識されないステータスを情報を与えないものとして扱うべきです(SHOULD)。
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] 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] 。
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] comp.risks 0000442001 0000441099 m [S] alt.rfc-writers.recovery 0000000004 0000000001 y [S]tx.ネイティブ.recovery 0000000089 0000000056 y [S] tx.natives.recovery.d 0000000011 0000000009 n [S] 。
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:
情報はニュースグループ ベースであり、ワイルドマットを指定することができます (MAY)。その場合、応答は名前がワイルドマットに一致するグループ (存在する場合) にのみ制限されます。例えば：
[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 つのフィールドで構成されます。最初のフィールドはニュースグループの名前です。2 番目は、このグループがこのニュース サーバー上に作成された時刻で、1970 年 1 月 1 日の開始からの秒数で測定されます。3 番目は、ニュースグループを作成したエンティティを説明するためのプレーン テキストです。多くの場合、これは 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 ACTIVE.TIMES [S] 215 情報が続きます [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] 。
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) によって返されるリストと一致すると仮定してはなりません (MUST NOT)。NEWGROUPS コマンド (セクション 7.3) は、この情報にアクセスするためのより良い方法を提供する可能性があり、この 2 つのコマンドの結果は、active.times リストの最も古いエントリより前の日付と時刻で後者が呼び出された場合を除いて、一貫している必要があります (SHOULD)。、その結果には余分なグループが含まれる場合があります。
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.
情報はニュースグループ ベースであり、ワイルドマットを指定することができます (MAY)。その場合、応答は名前がワイルドマットに一致するグループ (存在する場合) にのみ制限されます。
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 リストは、クライアントが投稿されるニュース記事の Distribution ヘッダーの内容の値を選択できるようにするために、一部の NNTP サーバーによって維持されます。このリストの各行は、コロン (「:」) で区切られた 3 つのフィールドで構成されます。最初のフィールドは重み、2 番目のフィールドはワイルドマット (単純なニュースグループ名など)、3 番目のフィールドは Distribution ヘッダー コンテンツの値です。例えば：
[C] LIST DISTRIB.PATS [S] 215 information follows [S] 10:local.*:local [S] 5:*:world [S] 20:local.here.*:thissite [S] .
[C] LIST DISTRIB.PATS [S] 215 情報が [S] 10:local.*:local [S] 5:*:world [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.
クライアントは、この情報を使用して、ニュースグループの名前を指定して適切な Distribution ヘッダーを構築してもよい (MAY)。そのためには、2 番目のフィールドがニュースグループ名と一致する行を特定し、その中から最も重みが高い行 (0 が最も低い) を選択し、3 番目のフィールドの値を使用して Distribution ヘッダーを構築する必要があります。
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 サーバーによって維持され、サーバー上で利用可能な各ニュースグループの名前とグループの目的に関する簡単な説明が含まれます。このリストの各行は、1 つ以上のスペースまたは TAB 文字 (通常は 1 つの TAB) で区切られた 2 つのフィールドで構成されます。最初のフィールドはニュースグループの名前で、2 番目のフィールドはグループの簡単な説明です。例えば：
[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 NEWSGROUPS [S] 215 の情報が続きます [S] misc.test General Usenet testing [S] alt.rfc-writers.recovery RFC Writers Recovery [S] tx.natives.recovery Texas 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.
リストでは、情報が入手できないニュースグループを省略してもよく、サーバー上で入手できないグループを含めてもよいです。クライアントは、リストが完全である、またはリストが LIST ACTIVE によって返されたリストと一致すると仮定してはなりません (MUST NOT)。
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 である必要があります。ただし、サーバーは外部ソースから情報を取得することがよくあります。これらのソースは異なるエンコーディング (他の方法で 128 から 255 の範囲のオクテットを使用するもの) を使用している可能性があり、その場合、サーバーはそれを変更せずに渡してもよい(MAY)。したがって、クライアントはそのような説明を受け取る準備ができていなければなりません。
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.
情報はニュースグループ ベースであり、ワイルドマットを指定することができます (MAY)。その場合、応答は名前がワイルドマットに一致するグループ (存在する場合) にのみ制限されます。
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.
このセクションは、Geoff Collyer によって開発された概要/NOV データベース [ROBE1995] に基づいています。
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.
メタデータ項目を生成するとき、サーバーはそれを自分で計算しなければならず、記事内で提供される関連する値を信頼してはなりません。(特に、アーティクル内の Lines または Bytes ヘッダーは、アーティクル内の正しい行数またはバイト数を指定していると想定してはなりません。) サーバーがアーティクルの異なる複数のコピーにアクセスできる場合、返される値は次のようにしなければなりません (MUST)。同じセッション中に取得された記事のコピーについては正しいものとします。
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-".
この仕様では、「:bytes」と「:lines」という 2 つのメタデータ項目が定義されています。他のメタデータ項目は拡張機能によって定義される場合があります。登録された拡張機能によって定義されるメタデータ項目の名前は、「:x-」で始まってはなりません。将来登録される拡張機能との衝突のリスクを避けるために、プライベート拡張機能によって定義されるメタデータ項目の名前は「:x-」で始まるべきです(SHOULD)。
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).
記事の :bytes メタデータ項目は 10 進整数です。これは、記事全体のオクテット数、つまりヘッダー、本文、および区切りの空行（CRLF ペアを 2 オクテットとして数え、応答を終了する CRLF の「.」と「ドット」に追加された「.」の両方を除く）のオクテット数と等しい必要があります（SHOULD）。詰め物」の目的）。
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.
o CRLF ペアを 1 オクテットとしてカウントします。
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 オクテットをカウントするためにアーティクルの 1 つのコピーを使用しますが、何らかの (許可された) 方法で異なる別のコピーを返します。
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).
記事の :lines メタデータ項目は 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 コマンドは、その時点でデータベースに一貫性があるすべてのフィールドをリストする必要があります (SHOULD)。そのようなフィールドは省略してもよいです (たとえば、データベースが一貫しているか不整合であるかが不明な場合)。データベースに一貫性がないフィールドやデータベースに保存されていないフィールドを含めてはなりません。したがって、ヘッダーが特定のアーティクルの LIST 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.
これらのルールは、データベースに保存されているフィールドが長期間一定であり、したがってデータベースの一貫性が保たれることを前提としています。保存されるフィールドのセットが変更されると、データベースが再構築されるか、変更後に受信した記事だけが残るまで、そのセットは不整合になります。したがって、LIST OVERVIEW.FMT からの出力を 2 回変更する必要があります。まず、フィールドの保存を停止する前に、フィールドを出力から削除する必要があります。その後、データベースが一貫していることがもう一度わかったら、新しいフィールドを出力に追加する必要があります(SHOULD)。
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 HEADERS コマンドはそれらを解決する際に LIST OVERVIEW.FMT コマンドと同じアプローチをとる必要があります (SHOULD)。
Indicating capability: OVER
表示能力：OVER
Syntax OVER message-id OVER range OVER
構文 OVER メッセージ ID OVER 範囲 OVER
Responses
反応
First form (message-id specified) 224 Overview information follows (multi-line) 430 No article with that message-id
最初のフォーム (メッセージ ID を指定) 224 概要情報が続きます (複数行) 430 そのメッセージ ID を持つ記事はありません
Second form (range specified) 224 Overview information follows (multi-line) 412 No newsgroup selected 423 No articles in that range
2 番目の形式 (範囲指定) 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
3 番目の形式 (現在の記事番号が使用されています) 224 概要情報が続きます (複数行) 412 ニュースグループが選択されていません 420 現在の記事番号が無効です
Parameters range Number(s) of articles message-id Message-id of article
パラメータの範囲 記事の数 message-id 記事のメッセージ ID
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 コマンドは、message-id で指定された記事、または現在選択されているニュースグループ内の指定された記事または記事範囲のデータベース内のすべてのフィールドの内容を返します。
The message-id argument indicates a specific article. The range argument may be any of the following:
message-id 引数は特定の記事を示します。range 引数は次のいずれかになります。
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 を返さなければなりません (MUST)。
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 応答コードに続く複数行のデータ ブロックとして返され、記事ごとに 1 行が含まれ、記事番号の番号順にソートされます。(引数がダッシュを含む範囲でない限り、データ ブロックには 1 行だけ存在することに注意してください。) 各行は、TAB で区切られた複数のフィールドで構成されます。フィールドが空の場合もあり (この場合、隣接する TAB が 2 つあります)、後続の一連の TAB が省略される場合があります。
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
「0」または記事番号 (下記を参照) 件名ヘッダーの内容 From ヘッダーの内容 日付ヘッダーの内容 メッセージ ID ヘッダーの内容 参照ヘッダーの内容 :bytes メタデータ項目 :lines メタデータ項目
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.
記事が message-id (コマンドの最初の形式) で指定されている場合、記事番号はゼロに置き換えられなければなりません (MUST)。ただし、現在選択されているニュースグループがあり、記事がそのグループに存在する場合、サーバーはそのグループ内の記事の番号。(詳細については ARTICLE コマンド (セクション 6.2.1) と STAT の例 (セクション 6.2.4.3) を参照してください。) コマンドの他の 2 つの形式では、記事番号を返さなければなりません (MUST)。
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 を削除し)、次に各 TAB を単一のスペースに置き換えることによって処理されます。記事内にそのようなヘッダーがない場合、そのようなメタデータ項目がない場合、またはその記事のデータベースにヘッダーや項目が保存されていない場合、対応するフィールドは空でなければなりません。
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 の文字を含めることはできないことに注意してください。それにも関わらず、サーバーはこれらの文字をチェックし、それぞれを 1 つのスペースで置き換えるべきです (たとえば、CR と最初の LF は展開プロセスによって削除されるため、CR LF LF TAB は 2 つのスペースになります)。これにより、不適合データに直面した場合の堅牢性が促進されます。この仕様の将来のバージョンでは、これらの文字が記事に登場することが許可される可能性もあります。
The server SHOULD NOT produce output for articles that no longer exist.
サーバーは、もう存在しない記事の出力を生成すべきではありません (SHOULD NOT)。
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 応答を返さなければなりません (MUST)。引数が範囲であるか省略されており、現在選択されているニュースグループが無効な場合は、412 応答を返さなければなりません (MUST)。引数が範囲であり、現在選択されているニュースグループにその番号範囲の記事が存在しない場合 (2 番目の番号が最初の番号より小さい場合も含めて)、423 応答を返さなければなりません (MUST)。引数が省略され、現在の記事番号が無効な場合は、420 応答を返さなければなりません (MUST)。
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 missc.test [C] OVER [S] 224 概要情報が続きます [S] 3000234|私は単なるテスト記事です|"デモ ユーザー" <nobody@example.com>|1998 年 10 月 6 日 04: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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] リーダー [S] OVER MSGID [S] アクティブなニュースグループの概要.FMT [S] をリストします。[C] OVER <45223423@example.com> [S] 224 概要情報が続きます [S] 0|私は単なるテスト記事|「デモ ユーザー」 <nobody@example.com>|6 Oct 1998 04: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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] リーダー [S] OVER [S] アクティブなニュースグループの一覧.FMT [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] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 missc.test [C] OVER 3000234-3000240 [S] 224 概要情報が続きます [S] 3000234|私は単なるテスト記事|「デモ ユーザー」 <nobody@example.com>|1998 年 10 月 6 日 04:38:40 -0500|<45223423@example.com>|<45454@example.net>|1234|17|外部参照: news.example.com misc.test:3000363 [S] 3000235|別のテスト記事|nobody@nowhere.to (デモ ユーザー)|1998 年 10 月 6 日 04:38:45 -0500|<45223425@to.to>||4818|37||配布: fi [S] 3000238|Re: 私は単なるテスト記事です|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 行目の「References」ヘッダーと Xref ヘッダーが欠落していること、最初と最後の行の末尾フィールドが欠落していること、およびまだ存在する記事の結果のみがあることに注意してください。
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 その他のテスト [S] 211 1234 3000234 3002322 その他のテスト [C] OVER 300256 [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 その他のテスト [S] 211 1234 3000234 3002322 その他のテスト [C] OVER 3000444-3000222 [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] OVER [S] 412 ニュースグループが選択されていません
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
[C] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] OVER [S] 420 現在の記事が選択されていません
Indicating capability: OVER
表示能力：OVER
Syntax LIST OVERVIEW.FMT
構文リスト概要.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
件名: 差出人: 日付: メッセージ ID: 参照: :bytes :lines
For compatibility with existing implementations, the last two lines MAY instead be:
既存の実装との互換性を保つため、最後の 2 行は次のようにしてもよい (MAY)。
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.
後続のすべての行は、ヘッダー名とそれに続く「:full」、またはメタデータの一部の名前のいずれかで構成されなければなりません。
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 出力の 2 番目から 8 番目のフィールドを記述していることに注意してください。「完全な」接尾辞 (大文字、小文字、またはその組み合わせを使用できる) は、対応するフィールドにヘッダー名が含まれていることを思い出させます。
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:
上記の OVER 出力例に対応する LIST OVERVIEW.FMT 出力の例 (推奨形式):
[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] メッセージ ID: [S] 参照: [S] :bytes [S] :lines [S] Xref:full [S] Distribution:full [S] 。
Example of LIST OVERVIEW.FMT output corresponding to the example OVER output above, in the alternative format:
上記の OVER 出力例に対応する LIST OVERVIEW.FMT 出力の別の形式の例:
[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] メッセージ ID: [S] 参照: [S] バイト: [S] 行: [S] Xref: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
2 番目の形式 (範囲指定) 225 ヘッダーが続きます (複数行) 412 ニュースグループが選択されていません 423 その範囲に記事はありません
Third form (current article number used) 225 Headers follow (multi-line) 412 No newsgroup selected 420 Current article number is invalid
3 番目の形式 (現在の記事番号が使用されています) 225 ヘッダーが続きます (複数行) 412 ニュースグループが選択されていません 420 現在の記事番号が無効です
Parameters field Name of field range Number(s) of articles message-id Message-id of article
パラメータ field フィールドの名前 範囲 記事の数 message-id 記事のメッセージ ID
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 コマンドは、message-id で指定された記事、または現在選択されているニュースグループ内の指定された記事または記事の範囲から特定のフィールドへのアクセスを提供します。記事または概要データベースから直接情報を取得してもよい(MAY)。ヘッダーの場合、実装はこのコマンドの使用をヘッダーの特定のリストに制限してもよいし、任意のヘッダーでの使用を許可してもよい(MAY)。message-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.
必須のフィールド引数は、コロンを省略したヘッダーの名前 (例: 「subject」)、または先頭のコロンを含むメタデータ項目の名前 (例: 「:bytes」) であり、大文字と小文字は区別されません。
The message-id argument indicates a specific article. The range argument may be any of the following:
message-id 引数は特定の記事を示します。range 引数は次のいずれかになります。
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 行が含まれます。(引数がダッシュを含む範囲でない限り、データ ブロックには 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.
記事が message-id (コマンドの最初の形式) で指定されている場合、記事番号はゼロに置き換えられなければなりません (MUST)。ただし、現在選択されているニュースグループがあり、記事がそのグループに存在する場合、サーバーはそのグループ内の記事の番号。(詳細については ARTICLE コマンド (セクション 6.2.1) と STAT の例 (セクション 6.2.4.3) を参照してください。) コマンドの他の 2 つの形式では、記事番号を返さなければなりません (MUST)。
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.) 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.
ヘッダーの内容は次のように変更されます。すべての CRLF ペアが削除され、各 TAB が単一のスペースに置き換えられます。(これは、OVER コマンド (セクション 8.3.2) によって実行されるのと同じ変換であり、NUL、CR、および LF に関する同じコメントが適用されることに注意してください。) ヘッダーとメタデータの区別が同じ意味を持つように見えることに注意してください。ヘッダーは常に記事から変更されずに取得されます。メタデータは常に計算されます。たとえば、「Lines」のリクエストは、行数が正確に記述されているかどうかに関係なく、指定された記事の「Lines」ヘッダーの内容を返します。一方、「:lines」のリクエストは行数のメタデータを返します。これは、ヘッダーの内容に関係なく、常に実際の行数です。
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 応答を返さなければなりません (MUST)。2 番目の引数が範囲であるか省略されており、現在選択されているニュースグループが無効な場合は、412 応答を返さなければなりません (MUST)。2 番目の引数が範囲であり、現在選択されているニュースグループにその番号範囲の記事が存在しない場合 (2 番目の番号が最初の番号より小さい場合も含めて)、423 応答を返さなければなりません (MUST)。2 番目の引数が省略され、現在の記事番号が無効な場合は、420 応答を返さなければなりません (MUST)。
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 コマンドを許可してもよい (MAY)。この点で、最初の (メッセージ ID) フォームの動作は、他のフォームの動作とは異なる場合があります。そうである場合、他のフィールドを要求しようとする試みに対して、成功した空の応答などの誤った結果を返すのではなく、汎用の 503 応答で応答しなければなりません (MUST)。
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 が概要データベースを使用し、それが要求されたフィールドに対して一貫性がない場合、サーバーは返せる結果を返すことができます (MAY)、または一般的な 503 応答で応答することもできます (MAY)。後者の場合、フィールドは LIST HEADERS からの出力に現れてはなりません (MUST NOT)。
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 その他のテスト [S] 211 1234 3000234 3002322 その他のテスト [C] HDR 件名 3000234-3000238 [S] 225 ヘッダーが続きます [S] 3000234 私は単なるテスト記事です [S] 3000235 [S] 3000237 Re: 私は単なるテスト記事 [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 その他のテスト [S] 211 1234 3000234 3002322 その他のテスト [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 subject <i.am.a.test.article@example.com> [S] 225 ヘッダー情報が続きます [S] 0 I am単なるテスト記事 [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 miss.test [S] 211 1234 3000234 3002322 miss.test [C] HDR subject [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] GROUP example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup [C] HDR subject 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] 503 HDR は Content-Type では許可されていません
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 によるアクセスのリストを要求 RANGE 範囲によるアクセスのリストを要求
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 HEADERS コマンドは、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 行が含まれます (ヘッダーの末尾のコロンを除き、メタデータ項目の先頭のコロンを含みます)。実装でヘッダーの取得が許可されている場合、リストにヘッダー名を含めてはなりませんが、特別なエントリ ":" (単独の単一コロン) を含めなければなりません。利用可能なメタデータ項目を明示的にリストしなければなりません (MUST)。リスト内の項目の順序は重要ではありません。サーバーは同じ注文を一貫して返す必要さえありません。リストは空であっても構いません (ただし、この状況では 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 コマンドからの出力にリストされるすべてのヘッダーとメタデータ項目を許可する必要があります (SHOULD)。
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 指定) を他の 2 つの形式 (範囲指定または現在のアーティクル番号の使用) とは異なる方法で処理する場合、次のことが適用されます。
o If the MSGID argument is specified, the results MUST be those available for the first form of the HDR command.
o MSGID 引数が指定されている場合、結果は HDR コマンドの最初の形式で利用可能な結果でなければなりません。
o If the RANGE argument is specified, the results MUST be those available for the second and third forms of the HDR command.
o RANGE 引数が指定されている場合、結果は HDR コマンドの 2 番目と 3 番目の形式で利用可能な結果でなければなりません。
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 HEADERS [S] サポートされる 215 個のヘッダー: [S] Subject [S] Message-ID [S] Xref [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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] リーダー [S] OVER [S] HDR [S] アクティブなニュースグループ ヘッダーの概要.FMT [S] をリストします。[C] LIST HEADERS [S] サポートされている 215 個のヘッダーとメタデータ項目: [S] Date [S] Distribution [S] From [S] Message-ID [S] References [S] Subject [S] Xref [S] :bytes[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 HEADERS [S] サポートされるメタデータ項目は 215 個です: [S] : [S] :lines [S] :bytes [S] :x-article-number [S] 。
Example of an implementation distinguishing the first form of the HDR command from the other two forms:
HDR コマンドの最初の形式を他の 2 つの形式から区別する実装の例:
[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 HEADERS RANGE [S] サポートされるメタデータ項目は 215 個です: [S] : [S] :lines [S] :bytes [S] 。[C] LIST HEADERS MSGID [S] サポートされている 215 個のヘッダーおよびメタデータ項目: [S] 日付 [S] 配布 [S] From [S] メッセージ ID [S] 参照 [S] 件名 [S] :lines [S]:バイト [S] :x 記事番号 [S] 。[C] LIST HEADERS [S] 215 個のヘッダーおよびメタデータ項目がサポートされています: [S] 日付 [S] 配布 [S] 差出人 [S] メッセージ ID [S] 参照 [S] 件名 [S] :lines [S] :バイト [S] 。
Note that :x-article-number does not appear in the last set of output.
:x-article-number は出力の最後のセットには表示されないことに注意してください。
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.
これらの間の非端末 <command-line>、<command-datastream>、<command-continuation>、および <response> は、クライアントとサーバーの間を流れるテキストを指定します。このドキュメントでは、各コマンドに関連する非端末に対して一貫した命名スキームが使用されており、登録された拡張機能の仕様で使用されるべきです(SHOULD)。
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 クライアントは <command-line> のインスタンスを送信します。EXAMPLE コマンドの構文は <example-command> です。
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>.
o クライアントがデータを即座にストリーミングするクライアントの場合、<command-datastream> のインスタンスを送信します。EXAMPLE コマンドの構文は <example-datastream> です。
o The server sends an instance of <response>.
o サーバーは <response> のインスタンスを送信します。
* 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 応答に引数がある場合、最初の行の構文は <response-000-content> です。
* 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>.
* 応答が複数行である場合、最初の行の後に <multi-line-data-block> が続きます。「ドット詰め」が削除された後のこのブロックの内容の構文は、(EXAMPLE コマンドに対する 000 応答の場合) <example-000-ml-content> であり、<multi-line-response-content のインスタンスです。>。
o While the latest response is one that indicates more data is required (in general, a 3xx response):
o 最新の応答は、さらにデータが必要であることを示す応答です (通常は 3xx 応答)。
* the client sends an instance of <command-continuation>; the syntax for the EXAMPLE continuation following a 333 response is <example-333-continuation>;
* クライアントは <command-continuation> のインスタンスを送信します。333 応答に続く EXAMPLE 継続の構文は <example-333-continuation> です。
* the server sends another instance of <response>, as above.
* サーバーは、上記のように、<response> の別のインスタンスを送信します。
(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).
この構文は、クライアントからサーバーに送信される内容を表す非終端 <command-line> を定義します (長さの制限についてはセクション 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
command =/ 記事コマンド / 本文コマンド / 機能コマンド / 日付コマンド / グループコマンド / hdr コマンド / head コマンド / help コマンド / ihave コマンド / last コマンド / list コマンド / listgroup コマンド/モードリーダーコマンド/新しいグループコマンド/新しいニュースコマンド/次のコマンド/オーバーコマンド/ポストコマンド/終了コマンド/統計コマンド
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-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
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
コマンドデータストリーム = 未定義 ;使用されません。拡張機能のフックとして提供されます。 command-continuation = ihave-335-continuation / post-340-continuation
ihave-335-continuation = encoded-article post-340-continuation = encoded-article
ihave-335-continuation = エンコードされた記事 post-340-continuation = エンコードされた記事
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> を定義します。つまり、<command> または <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
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
response-111-content = "111" SP date4y time response-211-content = "211" 3(SP 記事番号) SP ニュースグループ名 response-220-content = "220" SP 記事番号 SP メッセージ ID 応答-221-content = "221" SP 記事番号 SP メッセージ ID 応答-222-content = "222" SP 記事番号 SP メッセージ ID 応答-223-content = "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
multi-line-response-content =article-220-ml-content / body-222-ml-content /capability-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
article-220-ml-content = article body-222-ml-content = body capabilities-101-ml-content = version-line CRLF
Article-220-ml-content = 記事 body-222-ml-content = 本体機能-101-ml-content = バージョンライン 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)
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
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 能力 / 実装能力 / リスト能力 / モードリーダー能力 / 新しいニュース能力 / 過剰能力 / ポスト能力 / リーダー能力
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"
version-line = "VERSION" 1*(WS version-number)
version-number = 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.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
; distrib.pats
list-arguments =/ "DISTRIB.PATS"
list-content =/ list-distrib-pats-content
list-distrib-pats-content =
*(1*DIGIT ":" wildmat ":" distribution CRLF)
distribution = token
; headers
list-arguments =/ "HEADERS" [WS ("MSGID" / "RANGE")]
list-content =/ list-headers-content
list-headers-content = *(header-meta-name CRLF) /
*((metadata-name / ":") CRLF)
; newsgroups
list-arguments =/ "NEWSGROUPS" [WS wildmat]
list-content =/ list-newsgroups-content
list-newsgroups-content =
*(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)
This syntax defines the non-terminal <article>, which represents the format of an article as described in Section 3.6.
この構文は、セクション 3.6 で説明されている記事の形式を表す非終端 <article> を定義します。
article = 1*header CRLF body
header = header-name ":" [CRLF] SP header-content CRLF
header-content = *(S-CHAR / [CRLF] WS)
body = *(*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
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
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 = "*" / "?"
base64 = *(4base64-char) [base64-terminal]
base64-char = UPPER / LOWER / DIGIT / "+" / "/"
base64-terminal = 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 "."
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)
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
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> の定義と互換性がなければなりません。
command-datastream for each new command that immediately streams data;
データを直ちにストリーミングする新しいコマンドごとの command-datastream。
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-initial-response-content> の定義と互換性がなければなりません。
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;
複数行の応答を持つ新しい応答コードごとの multi-line-response-content - 構文は、応答コードと終了オクテットを含む行が削除され、「ドット詰め」が取り消された後の応答を表示しなければなりません。
capability-entry for each new capability label - the syntax of each entry MUST be compatible with the definition of <X-capability-entry>;
新しい機能ラベルごとに、capability-entry - 各エントリの構文は、<X-capability-entry> の定義と互換性がなければなりません。
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-command> の定義と互換性がなければなりません。
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 コマンドの新しい各バリアントの list-content - 構文は、215 応答コードと終了オクテットを含む行が削除され、「ドット詰め」が取り消された後の応答を表示しなければなりません。
The =/ notation of ABNF [RFC4234] and the naming conventions described in Section 9.1 SHOULD be used for this.
これには、ABNF [RFC4234] の =/ 表記とセクション 9.1 で説明されている命名規則を使用する必要があります (SHOULD)。
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 非ターミナル <command-line>、<command-datastream>、<command-continuation>、<response>、および <multi-line-response-content> はプロトコルの基本概念を記述しており、他のものでは参照されません。ルール;
o the non-terminal <base64> is provided for the convenience of extension authors and is not referred to by any rule in this specification;
o 非終端 <base64> は、拡張機能作成者の便宜のために提供されており、この仕様のどの規則でも参照されません。
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.
o 非終端の <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] は、国際化が重要な問題とは見なされなかった時代に書かれました。そのため、実際にはほぼすべての既知の実装が 8 ビット クリーンですが、すべての通信が ASCII で行われ、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.
それ以来、Usenet と NNTP は世界中に広がりました。言語と文字セットの問題を処理するための標準が存在しないため、国、ニュースグループ階層、個人は、自分たちにとっては効果的でも、他の国では必ずしも適切であるとは限らないさまざまな解決策を見つけてきました。たとえば、ニーズに適したデフォルトの 8 ビット文字セット (西ヨーロッパの ISO/IEC 8859-1 やロシアの KOI-8 など) を採用している企業もあれば、ASCII (US-ASCII または各国のバリアントのいずれか) を使用している企業もあります。ヘッダーにはローカル 16 ビット文字セットを使用しますが、記事本文にはローカル 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.
一般に受け入れられている点の 1 つは、アーティクルには先頭ビットが設定されたオクテットを含めることができ、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.
この仕様は、NNTP を US-ASCII [ANSI1986] から UTF-8 [RFC3629] に拡張します。以下で説明する 2 つの領域を除き、UTF-8 (US-ASCII のスーパーセット) は必須であり、実装では他のエンコーディングを使用してはなりません (MUST NOT)。
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 ヘッダーの名前 (「From」や「Subject」など) は 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] などのエンコーディングを使用すべきです (SHOULD)。現時点では、8 ビット エンコーディング (UTF-8 を含む) は相互運用性の問題を引き起こす可能性があるため、使用すべきではありません (SHOULD NOT)。
o The character set of article bodies SHOULD be indicated in the article headers, and this SHOULD be done in accordance with MIME.
o 記事本文の文字セットは記事ヘッダーで示される必要があり (SHOULD)、これは MIME に従って行われる必要があります (SHOULD)。
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 コマンドへの応答など) を導出することができます (MAY)。実装では、そのような記事とデータを正確かつ変更せずに転送しなければなりません。記事や派生データを変換または再エンコードしようとしてはなりません。(ただし、クライアントまたはサーバーは、記事をさらに検討した結果、投稿または転送することが不適切であると判断した場合、記事を投稿または転送しないことを選択することができます。)
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 NEWSGROUPS コマンド (セクション 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.
o この仕様ではニュースグループ名に UTF-8 を許可していますが、RFC 1036 の後継 [RFC1036] が別のアプローチを標準化するまでは、US-ASCII に制限すべきです (SHOULD)。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.
o RFC 1036 の後継が他のエンコード方式を標準化しない限り、ニュースグループの説明は US-ASCII または UTF-8 であるべきです (SHOULD)。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 外部ソースからこのデータを取得する実装では、たとえ上記の要件を満たしていない場合でも、データを正しく処理しなければなりません (MUST)。実装 (特にクライアント) は、そのようなデータを正しく処理しなければなりません (MUST)。
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 の主な用途は、RFC 1036 に準拠した記事 (ネットニュース記事) を送信することですが、他の形式にも使用されます (付録 A を参照)。したがって、記事の形式に関連する国際化の問題は、関連する仕様で対処することが最も適切です。ネットニュース記事の場合、これは RFC 1036 の後継です。電子メール メッセージの場合、これは RFC 2822 [RFC2822] です。
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 に制限することは、完全な解決策ではありません。特に、新しいニュースグループ名が作成された場合、またはユーザーがニュースグループ名の入力を求められた場合、何らかの正規化スキームを実行する必要があります。この仕様は、その正規化を定義しようとするものではありません。この分野では、記事形式の仕様と合わせてさらなる作業が必要です。そのような仕様が公開されるまで、実装はニュースグループ名をオクテットごとに一致させる必要があります(SHOULD)。承認されたスキームは「エッジで」適用されることが予想されるため、オクテットごとの比較は、すべてではないにしても、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 で説明されているように、X で始まるラベルは私的使用のために予約されていますが、他のすべての名前は、標準化トラックの RFC の仕様または IESG 承認の実験プロトコルの定義に関連付けられることが期待されます。
Different entries in the registry MUST use different capability labels.
レジストリ内の異なるエントリは、異なる機能ラベルを使用しなければなりません (MUST)。
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.
レジストリ内の異なるエントリで同じコマンド名を使用してはなりません。この目的のために、2 番目以降のキーワードによって区別されるバリアント (例: "LIST HEADERS" と "LIST OVERVIEW.FMT") は、異なるコマンドとしてカウントされます。2 つの拡張機能で同じコマンドを使用する必要がある場合は、単一の統一された仕様を登録する必要があります。
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 サーバー管理者が特定の一連のニュース記事の拡散の可能性を自信を持って報告できるように、ニュース記事の配信を管理するための効果的でわかりやすいメカニズムを提供する必要があります (SHOULD)。
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 の拡張機能を作成することが許可されています。そのような拡張子の 1 つが [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 名の意図的な誤った関連付けに基づくセキュリティ攻撃を受ける傾向があります。。クライアントとサーバーは、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 名の関連付けを確認するためにネーム リゾルバーに依存する必要があります (SHOULD)。多くのプラットフォームはすでに、必要に応じてホスト名ルックアップをローカルにキャッシュでき、そのように構成する必要があります(SHOULD)。ただし、ネーム サーバーによって報告された TTL (Time To Live) 情報により、キャッシュされた情報が引き続き有効であると考えられる場合にのみ、これらのルックアップをキャッシュすることが適切です。
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] は、特定のオクテット シーケンスのみを許可し、その他のオクテット シーケンスは不正または「不正」であると指定します。Unicode 標準は、不正なシーケンスに関連する多くのセキュリティ問題を特定し、準拠する実装によるそれらの生成を禁止します。
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:
この仕様の実装では、不正なシーケンスや不正なシーケンスを生成してはならず、それらを検出して適切な措置を講じるべきです(SHOULD)。これには次のものが含まれる可能性があります。
o Generating a 501 response code.
o 501 応答コードを生成します。
o Replacing such sequences by the sequence %xEF.BF.BD, which encodes the "replacement character" U+FFFD.
o このようなシーケンスは、「置換文字」U FFFD をエンコードするシーケンス %xEF.BF.BD に置き換えられます。
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.
最後のケースでは、実装は、有効性チェックやセキュリティ チェックをバイパスするために置換を使用できないことを保証しなければなりません (MUST)。たとえば、不正なシーケンス %xC0.A0 は、スペース (%x20) の過度に長いエンコードです。コマンド ラインで正しいエンコーディングに置き換える場合は、コマンド ラインが個々の引数に解析される前に行う必要があります。置換が解析後に行われた場合、スペースが埋め込まれた引数を生成する可能性がありますが、これは禁止されています。「置換文字」の使用は、US-ASCII 以外の文字が存在する場合はどこでも許可されるため、この問題は発生しません。実装では、NNTP ストリームの一般的な構造がそのまま残る最初の 2 つのソリューションのいずれかを使用する必要があり (SHOULD)、適切に解析できなくなった場合は接続を閉じる必要があります (SHOULD)。
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] CAPABILITIES [S] 101 機能リスト: [S] VERSION 2 [S] READER [S] NEWNEWS [S] POST [S]XENCRYPT [S] アクティブなニュースグループをリストします [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] 機能 [S] 101 機能リスト: [S] バージョン 2 [S] リーダー [S] ニュース [S] 投稿 [S] XSECRET [S] アクティブなニュースグループのリスト [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 fred flintstone [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.
この文書は、Russ Allbery と Ned Freed が議長を務める NNTP ワーキング グループの現在および過去のメンバーによる多大な努力の成果です。彼らなしでは制作できなかったでしょう。
The author acknowledges the original authors of NNTP as documented in RFC 977 [RFC977]: Brian Kantor and Phil Lapsey.
著者は、RFC 977 [RFC977] に記載されている NNTP のオリジナルの作成者である BrianKantor と Phil Lapsey を認めます。
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.
o エリオット・リアが委員長を務めるNNTP委員会の活動。この文書の構成は、この作業グループから入手可能な最新バージョンの影響を受けています。その文書の機械可読なオリジナルのソースを寛大に提供してくださった Eliot に特別な感謝を申し上げます。
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.
o DRUMS ワーキング グループの成果、特に RFC 1869 [RFC1869] は、CAPABILITIES コマンドとこの文書で詳述する拡張メカニズムにつながる最初の考え方を推進しました。
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.
o RFC 2616 [RFC2616] の著者は、HTTP に関して考慮すべきセキュリティ問題の具体的かつ関連する例を提供しました。NNTP にも同様の考慮事項が多く存在するため、関連する例はいくつかのマイナーな書き直しとともにここに含まれています。
o The comments and additional information provided by the following individuals in preparing one or more of the progenitors of this document:
o この文書の 1 つ以上の作成時に次の個人によって提供されたコメントと追加情報:
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.
Rick Adams RN ニュース リーダーの NNTP 拡張機能の元の作成者であり、Bnews の最後のメンテナです。
Stan Barber Original author of the NNTP extensions to the news readers that are part of Bnews.
Stan Barber Bnews の一部であるニュース リーダーへの NNTP 拡張機能の元の作成者。
Geoff Collyer Original author of the OVERVIEW database proposal and one of the original authors of CNEWS.
Geoff Collyer OVERVIEW データベース提案の元の著者であり、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).
Wayne Davison RN ニュース リーダー (一般に TRN と呼ばれる) の最初のスレッド拡張機能の作成者。
Geoff Huston Original author of ANU NEWS.
ジェフ・ヒューストン ANU NEWS の原著者。
Phil Lapsey Original author of the UNIX reference implementation for NNTP.
Phil Lapsey NNTP の UNIX リファレンス実装の元の著者。
Iain Lea Original maintainer of the TIN news reader.
Iain Lea TIN ニュース リーダーの元のメンテナ。
Chris Lewis First known implementer of the AUTHINFO GENERIC extension.
Chris Lewis AUTHINFO GENERIC 拡張機能の最初の既知の実装者。
Rich Salz Original author of INN.
リッチ・ザルツ INNの原作者。
Henry Spencer One of the original authors of CNEWS.
ヘンリー・スペンサー CNEWS のオリジナル著者の 1 人。
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
マティアス・アンドリー グレッグ・アンドリュック ダニエル・バークレー マウリツィオ・コドーニョ マーク・クリスピン アンドリュー・ギアス ユルゲン・ヘルビング スコット・ホレンベック ウルス・ヤンセン チャールズ・リンゼイ エイド・ロヴェット デヴィッド・マグダ ケン・マーチソン フランソワ・ペティヨン ピーター・ロビンソン ロブ・シエンボルスキー ハワード・スワインハート ルート・ファン・トル ジェフリー・ヴィノクール エリック・ウォームリンク
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>
[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]Kantor、B.、および P. Lapsley、「ネットワーク ニュース転送プロトコル」、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] Freed, N. および N. Borenstein、「多目的インターネット メール拡張機能 (MIME) パート 1: インターネット メッセージ本体のフォーマット」、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] Moore, 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] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、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] Crocker, 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.、Murchison, K.、および C. Newman、「認証のためのネットワーク ニュース転送プロトコル (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. Murchison、「ストリーミング フィード用のネットワーク ニュース転送プロトコル (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] Murchison, K.、Vinocur, J.、および C. Newman、「ネットワーク ニュース転送プロトコル (NNTP) でのトランスポート層セキュリティ (TLS) の使用」、RFC 4642、2006 年 10 月。
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.
[RFC1036] Horton, M. および R. Adams、「USENET メッセージ交換の標準」、RFC 1036、1987 年 12 月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305] Mills, 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.、Freed, N.、Rose, M.、Stefferud, E.、D. Crocker、「SMTP Service Extensions」、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] Fielding, R.、Gettys, J.、Mogul, J.、Frystyk, H.、Masinter, L.、Leach, P.、および T. Berners-Lee、「ハイパーテキスト転送プロトコル -- HTTP/1.1」、RFC 2616、1999 年 6 月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629] Rose, M.、「XML を使用した I-D および RFC の作成」、RFC 2629、1999 年 6 月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick, P.、「インターネット メッセージ フォーマット」、RFC 2822、2001 年 4 月。
[RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[RFC2980] Barber, S.、「Common NNTP Extensions」、RFC 2980、2000 年 10 月。
[ROBE1995] Robertson, R., "FAQ: Overview database / NOV General Information", January 1995.
[ROBE1995] Robertson, R.、「FAQ: 概要データベース / NOV 一般情報」、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>
著者が知る限り、この文書の最終的なコピーは存在しません。これは、Usenet の記事 <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.、「INN 1.4 ディストリビューションの wildmat(3) のマニュアル ページ、リビジョン 1.10」、1992 年 4 月。
There is no definitive copy of this document known to the author.
著者が知る限り、この文書の最終的なコピーは存在しません。
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] に準拠した電子メール メッセージを転送するために使用されることもあります (このような記事をここでは「電子メール 記事」と呼びます)。この状況では、物品はこの仕様と他の仕様の両方に準拠する必要があります。この付録では、いくつかの関連する問題について説明します。
NNTP allows a header line to be folded (by inserting a CRLF pair) before any space or TAB character.
NNTP では、スペースまたは TAB 文字の前にヘッダー行を (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.
電子メール記事とネットニュース記事の両方で、各ヘッダー行にスペースまたはタブ以外の少なくとも 1 オクテットが必要です。したがって、折り畳みは、連続するスペースまたは TAB の各シーケンス内の 1 つの点でのみ発生します。さらに、ネットニュース記事では、ヘッダー名、コロン、およびその後のスペースをすべて最初の行に含める必要があります。折り畳みはそのスペースを超えてのみ発生する可能性があります。最後に、一部の非準拠ソフトウェアは、行の末尾のスペースとタブを削除します。したがって、スペースまたは TAB の後にヘッダーを折りたたむことはお勧めできない場合があります。
For maximum safety, header lines SHOULD conform to the following syntax rather than to that in Section 9.7.
安全性を最大限に高めるため、ヘッダー行はセクション 9.7 の構文ではなく、次の構文に準拠する必要があります (SHOULD)。
header = header-name ":" SP [header-content] CRLF
header-content = [WS] token *( [CRLF] WS token )
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>
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 実装では、これら 3 つのうち 1 つだけがプロトコルに現れ、残りの 2 つは必要に応じて (クライアントが NEWNEWS コマンドの結果を内部データベースと照合するときなどに) 変換されるようにする必要があります。メッセージ ID の。RFC 1036 [RFC1036] では、2 つの異なる文字列を同一のものとして扱うことは決してないことに注意してください。その後継バージョン (執筆時点) では、メッセージ ID の構文が制限されており、RFC 2822 が 2 つの文字列を同等のものとして扱う場合、それらのうちの 1 つだけが有効になります (上記の例では、最初の文字列のみが有効です)。
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 を使用する必要があります (SHOULD)。電子メールやネットニュースの記事に使用すべき一般的なアプローチは、「Message-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 が提供されます。サーバーはそれを使用するか、記事の内容から決定することができます (MAY)。ただし、どちらを行う場合でも、IHAVE コマンドが同じ引数とアーティクルで繰り返された場合、それが重複として認識されることを保証する必要があります (SHOULD)。
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 が含まれていない場合は、メッセージ ID を合成しなければなりません (MUST)。これは、たとえば、単純なシーケンス番号である場合もあれば、記事が到着した日付と時刻に基づく場合もあります。電子メールまたはネットニュース記事を処理する場合、グローバルな一貫性と一意性を確保するために、Message-ID ヘッダーを追加する必要があります (SHOULD)。
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):
message-id は記事内の Message-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!demo!whitehouse!not-for-mail [S] メッセージ ID: <1234@example.net> [S] From: "Demo User" <nobody@example.net> [S] ニュースグループ: misc.test [S] 件名: 私は単なるテスト記事です [S] 日付: 1998 年 10 月 6 日 04:38:40 -0500 [S] 組織: Net、Uncertain、テキサス州の例 [S] 。
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 サーバーは、文字をフィルタリングしたり、行を折りたたんだり制限したり、その他の方法で受信テキストを処理したりせず、受信記事を変更せずにそのソフトウェアに渡す必要があります (SHOULD)。
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 が割り当てられるようにすることが重要です。したがって、電子メールまたはネットニュース記事の場合、投稿された記事には「Message-ID」という名前のヘッダーが含まれている必要があり、このヘッダーの内容は毎回同じである必要があります。サーバーは、このヘッダーの同じ内容を持つ 2 つの POST 記事が同一であると認識され、それらの内容がメッセージ ID として使用するのに適しているかどうかに関係なく、同じメッセージ ID が割り当てられることを保証する必要があります (SHOULD)。
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 |
+-------------------+-----------------------+---------------+
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.
応答コード 100 (複数行) 生成元: HELP 意味: ヘルプ テキストが続きます。
Response code 101 (multi-line) Generated by: CAPABILITIES Meaning: capabilities list follows.
応答コード 101 (複数行) 生成者: CAPABILITIES 意味: 機能リストは次のとおりです。
Response code 111 Generated by: DATE 1 argument: yyyymmddhhmmss Meaning: server date and time.
応答コード 111 生成元: DATE 1 引数: yyyymmddhhmmss 意味: サーバーの日付と時刻。
Response code 200 Generated by: initial connection, MODE READER Meaning: service available, posting allowed.
応答コード 200 生成元: 初期接続、MODE READER 意味: サービスが利用可能、投稿は許可されています。
Response code 201 Generated by: initial connection, MODE READER Meaning: service available, posting prohibited.
レスポンス コード 201 生成元: 初期接続、MODE READER 意味: サービスが利用可能、投稿は禁止されています。
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.
(複数行ではありません) 生成元: GROUP 4 引数: 数値 low high group 意味: グループが選択されました。
(multi-line) Generated by: LISTGROUP 4 arguments: number low high group Meaning: article numbers follow.
(複数行) 生成者: LISTGROUP 4 つの引数: number low high group 意味: 記事番号が続きます。
Response code 215 (multi-line) Generated by: LIST Meaning: information follows.
応答コード 215 (複数行) 生成元: LIST 意味: 情報が続きます。
Response code 220 (multi-line) Generated by: ARTICLE 2 arguments: n message-id Meaning: article follows.
応答コード 220 (複数行) 生成元: ARTICLE 2 引数: n message-id 意味: 記事が続きます。
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.
応答コード 222 (複数行) 生成元: BODY 2 引数: n メッセージ ID 意味: 記事本文が続きます。
Response code 223 Generated by: LAST, NEXT, STAT 2 arguments: n message-id Meaning: article exists and selected.
応答コード 223 生成元: LAST、NEXT、STAT 2 引数: n メッセージ ID 意味: 記事が存在し、選択されています。
Response code 224 (multi-line) Generated by: OVER Meaning: overview information follows.
応答コード 224 (複数行) 生成者: OVER 意味: 概要情報が続きます。
Response code 225 (multi-line) Generated by: HDR Meaning: headers follow.
応答コード 225 (複数行) 生成元: HDR 意味: ヘッダーが続きます。
Response code 230 (multi-line) Generated by: NEWNEWS Meaning: list of new articles follows.
レスポンス コード 230 (複数行) 生成者: NEWNEWS 意味: 新しい記事のリストが続きます。
Response code 231 (multi-line) Generated by: NEWGROUPS Meaning: list of new newsgroups follows.
応答コード 231 (複数行) 生成者: NEWGROUPS 意味: 新しいニュースグループのリストが続きます。
Response code 235 Generated by: IHAVE (second stage) Meaning: article transferred OK.
レスポンス コード 235 生成者: IHAVE (第 2 段階) 意味: 記事は転送されました。
Response code 240 Generated by: POST (second stage) Meaning: article received OK.
レスポンス コード 240 生成元: POST (第 2 段階) 意味: 記事は正常に受信されました。
Response code 335 Generated by: IHAVE (first stage) Meaning: send article to be transferred.
レスポンス コード 335 生成者: IHAVE (第 1 段階) 意味: 転送対象の記事を送信します。
Response code 340 Generated by: POST (first stage) Meaning: send article to be posted.
レスポンスコード 340 生成者：POST（第 1 段階） 意味：投稿する記事を送信します。
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.
応答コード 411 生成者: GROUP、LISTGROUP 意味: そのようなニュースグループはありません。
Response code 412 Generated by: ARTICLE, BODY, GROUP, HDR, HEAD, LAST, LISTGROUP, NEXT, OVER, STAT Meaning: no newsgroup selected.
応答コード 412 生成元: ARTICLE、BODY、GROUP、HDR、HEAD、LAST、LISTGROUP、NEXT、OVER、STAT 意味: ニュースグループが選択されていません。
Response code 420 Generated by: ARTICLE, BODY, HDR, HEAD, LAST, NEXT, OVER, STAT Meaning: current article number is invalid.
レスポンス コード 420 生成元: ARTICLE、BODY、HDR、HEAD、LAST、NEXT、OVER、STAT 意味: 現在の記事番号が無効です。
Response code 421 Generated by: NEXT Meaning: no next article in this group.
応答コード 421 生成者: NEXT 意味: このグループには次の記事がありません。
Response code 422 Generated by: LAST Meaning: no previous article in this group.
応答コード 422 生成者: LAST 意味: このグループには以前の記事がありません。
Response code 423 Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT Meaning: no article with that number or in that range.
レスポンス コード 423 生成元: ARTICLE、BODY、HDR、HEAD、OVER、STAT 意味: その番号またはその範囲の記事がありません。
Response code 430 Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT Meaning: no article with that message-id.
応答コード 430 生成元: ARTICLE、BODY、HDR、HEAD、OVER、STAT 意味: そのメッセージ ID を持つ記事はありません。
Response code 435 Generated by: IHAVE (first stage) Meaning: article not wanted.
応答コード 435 生成者: IHAVE (第 1 段階) 意味: 記事は必要ありません。
Response code 436 Generated by: IHAVE (either stage) Meaning: transfer not possible (first stage) or failed (second stage); try again later.
応答コード 436 生成元: IHAVE (いずれかのステージ) 意味: 転送不可能 (第 1 ステージ) または失敗 (第 2 ステージ)。あとでもう一度試してみてください。
Response code 437 Generated by: IHAVE (second stage) Meaning: transfer rejected; do not retry.
応答コード 437 生成元: IHAVE (第 2 段階) 意味: 転送が拒否されました。再試行しないでください。
Response code 440 Generated by: POST (first stage) Meaning: posting not permitted.
レスポンス コード 440 生成元: POST (第 1 段階) 意味: 投稿は許可されていません。
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).
初期接続と MODE 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] のエラー。
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.
o 正式な構文仕様 (セクション 9) が追加されました。
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 デフォルトの文字セットは US-ASCII [ANSI1986] から UTF-8 [RFC3629] に変更されました (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 すべての記事にはメッセージ ID が必要であり、一部の応答で RFC 977 で使用される「<0>」プレースホルダーが削除されます。
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.
o RFC 977 (「wildmats」、セクション 4) ですでに文書化されているニュースグループ名マッチング機能が明確化され、拡張されています。新しい機能 (コンマや感嘆符の使用など) は、プロトコル内でワイルドマットが出現する場所であればどこでも許可されます。
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:
o 応答コードの背後にある原則 (セクション 3.2) が整理されました。特に：
* 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).
o 記事の番号付けのルール (セクション 6) が明確になりました (セクション 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 NEWNEWS (セクション 7.4) および NEWGROUPS (セクション 7.3) コマンドでは 4 桁の年が許可されます (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) が大幅に拡張されました。オリジナルは LIST ACTIVE として利用可能ですが、新しいバリアントには ACTIVE.TIMES、DISTRIB.PATS、および NEWSGROUPS が含まれます。新しい「m」ステータス フラグが LIST ACTIVE 応答に追加されます。
o A new CAPABILITIES command (Section 5.2) allows clients to determine what facilities are supported by a server.
o 新しい CAPABILITIES コマンド (セクション 5.2) を使用すると、クライアントはサーバーでサポートされている機能を判断できます。
o The DATE command (Section 7.1) is adopted from RFC 2980 effectively unchanged.
o DATE コマンド (セクション 7.1) は、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.
o LISTGROUP コマンド (セクション 6.1.2) は RFC 2980 から採用されています。オプションの range 引数が追加され、211 初期応答行は GROUP コマンドからの 211 応答と同じ形式になりました。
o The MODE READER command (Section 5.3) is adopted from RFC 2980 and its meaning and effects clarified.
o MODE 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 HEADERS (セクション 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) が形式化され、Bytes および Lines 擬似ヘッダーを非推奨にすることが可能になりました。
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.Feather THUS plc 322 Regents Park Road London N3 2QQ United Kingdom
Phone: +44 20 8495 6138
Fax: +44 870 051 9937
EMail: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC エディター機能の資金は、IETF Administrative Support Activity (IASA) によって提供されます。