RFC3977 日本語訳
3977 Network News Transfer Protocol (NNTP). C. Feather. October 2006. (Format: TXT=247440 bytes) (Obsoletes RFC0977) (Updates RFC2980) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Feather Request for Comments: 3977 THUS plc Obsoletes: 977 October 2006 Updates: 2980 Category: Standards Track
コメントを求めるワーキンググループC.羽の要求をネットワークでつないでください: 3977THUS plc Obsoletes: 977 2006年10月は以下をアップデートします。 2980年のカテゴリ: 標準化過程
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP.
ネットワークの電子情報を転送するプロトコル(NNTP)は、今日、10年間の間、インターネットで使用中であり、使用中の最もポピュラーなプロトコル(ボリュームに従った)の1つのままで残っています。 このドキュメントは、RFC977との交換であり、公式にプロトコル仕様をアップデートします。 それは、RFC977の何らかのあいまいさをはっきりさせて、何らかの新しいベースの機能性を含んで、標準化された拡大を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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 著者注. . . . . . . . . . . . . . . . . . . . . . 4 2。 記法. . . . . . . . . . . . . . . . . . . . . . . . . . 5 3。 基本概念. . . . . . . . . . . . . . . . . . . . . . . 6 3.1。 コマンドと応答. . . . . . . . . . . . . . . . . 6 3.1.1。 マルチ線データは.83.2を妨げます。 応答は.1に.93.2をコード化します。 一般的な応答は.103.2に.1に.1をコード化します。 例. . . . . . . . . . . . . . . . . . . . 12 3.3。 能力と拡大. . . . . . . . . . . . . . . 14 3.3.1。 能力記述. . . . . . . . . . . . . . . 14 3.3.2。 標準の能力. . . . . . . . . . . . . . . . 15 3.3.3。 拡大. . . . . . . . . . . . . . . . . . . . . 16 3.3.4。 IANAレジスタ. . . . . . . . . . . . . . . . 18 3.4に頭文字をつけてください。 義務的で任意のコマンド. . . . . . . . . . . . . 20
Feather Standards Track [Page 1] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[1ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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
3.4.1. 読書とトランジットサーバ. . . . . . . . . . . . . 21 3.4.2。 モードの切り換え. . . . . . . . . . . . . . . . . . . 21 3.5。 パイプライン処理. . . . . . . . . . . . . . . . . . . . . . . 22 3.5.1。 例. . . . . . . . . . . . . . . . . . . . . . 23 3.6。 第.244条。 WILDMATは.254.1をフォーマットします。 Wildmat構文. . . . . . . . . . . . . . . . . . . . . 26 4.2。 Wildmat意味論. . . . . . . . . . . . . . . . . . . . 26 4.3。 拡大. . . . . . . . . . . . . . . . . . . . . . . 27 4.4。 例. . . . . . . . . . . . . . . . . . . . . . . . 27 5。 セッション機関は.285.1を命令します。 接続. . . . . . . . . . . . . . . . . . . 28 5.2に頭文字をつけてください。 能力. . . . . . . . . . . . . . . . . . . . . . 29 5.3。 モード読者. . . . . . . . . . . . . . . . . . . . . . . 32 5.4。 .346をやめてください。 記事任命と検索. . . . . . . . . . . . . . . . 35 6.1。 グループと記事選択. . . . . . . . . . . . . . . 36 6.1.1。 グループ. . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.2。 LISTGROUP. . . . . . . . . . . . . . . . . . . . . . 39 6.1.3。 .426.1に、.4に持続します。 次の.446.2。 記事と記事部. . . . . . . 45 6.2の.1の検索。 第.466.2条.2。 ヘッド. . . . . . . . . . . . . . . . . . . . . . . . 49 6.2.3。 ボディー. . . . . . . . . . . . . . . . . . . . . . . . 51 6.2.4。 スタット. . . . . . . . . . . . . . . . . . . . . . . . 53 6.3。 記事任命. . . . . . . . . . . . . . . . . . . . . 56 6.3.1。 ポスト. . . . . . . . . . . . . . . . . . . . . . . . 56 6.3.2。 IHAVE. . . . . . . . . . . . . . . . . . . . . . . . 58 7。 情報は.617.1を命令します。 .617.2の日付を入れてください。 .627.3を助けてください。 NEWGROUPS. . . . . . . . . . . . . . . . . . . . . . . . 63 7.4。 NEWNEWS. . . . . . . . . . . . . . . . . . . . . . . . . 64 7.5。 時間. . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.5.1。 例. . . . . . . . . . . . . . . . . . . . . . 66 7.6。 リストは.1に.667.6を命令します。 リスト. . . . . . . . . . . . . . . . . . . . . . . . 67 7.6.2。 標準のリストキーワード. . . . . . . . . . . . . . . 69 7.6.3。 リストアクティブな. . . . . . . . . . . . . . . . . . . . . 70 7.6.4。 ACTIVE.TIMES. . . . . . . . . . . . . . . . . . 71 7.6.5を記載してください。 DISTRIB.PATS. . . . . . . . . . . . . . . . . . 72 7.6.6を記載してください。 ニュースグループ. . . . . . . . . . . . . . . . . . . 73 8を記載してください。 記事分野アクセスは.738.1を命令します。 記事メタデータ. . . . . . . . . . . . . . . . . . . . 74 8.1.1。 :bytesメタデータの品目. . . . . . . . . . . . . . 74 8.1.2。 :linesメタデータの品目. . . . . . . . . . . . . . 75 8.2。 データベースの一貫性. . . . . . . . . . . . . . . . . . 75
Feather Standards Track [Page 2] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[2ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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
8.3. .768.4以上。 OVERVIEW.FMT. . . . . . . . . . . . . . . . . . . . 81 8.5を記載してください。 HDR. . . . . . . . . . . . . . . . . . . . . . . . . . . 83 8.6。 ヘッダー. . . . . . . . . . . . . . . . . . . . . . 87 9を記載してください。 NNTP. . . . . . . . . . . . . . . . 90 9.1のためにBNF構文を増大させました。 序論. . . . . . . . . . . . . . . . . . . . . . 90 9.2。 コマンド. . . . . . . . . . . . . . . . . . . . . . . . 92 9.3。 継続. . . . . . . . . . . . . . . . . . 93 9.4を命令してください。 応答. . . . . . . . . . . . . . . . . . . . . . . . 93 9.4.1。 一般的な応答. . . . . . . . . . . . . . . . . . 93 9.4.2。 応答線コンテンツ. . . . . . . . . . . 94 9.4.3に頭文字をつけてください。 マルチ線応答コンテンツ. . . . . . . . . . . . 94 9.5。 能力は.959.6を裏打ちします。 異形. . . . . . . . . . . . . . . . . . . . . . 96 9.7を記載してください。 第.979.8条。 一般非端末.979.9。 拡大と合法化. . . . . . . . . . . . . . . . 99 10。 国際化問題. . . . . . . . . . . . .100 10.1。 序論と歴史的な状況. . . . . . . . . .100 10.2。 この仕様. . . . . . . . . . . . . . . . . . .101 10.3。 未解決の問題. . . . . . . . . . . . . . . . . . .102 11。 IANA問題. . . . . . . . . . . . . . . . . . . . .103 12。 セキュリティ問題. . . . . . . . . . . . . . . . . . .103 12.1。 個人的で独占である情報. . . . . . . . . .104 12.2。 サーバログ情報. . . . . . . . . . . . .104 12.3の乱用。 弱い認証とアクセスは.10412.4を制御します。 DNSスプーフィング. . . . . . . . . . . . . . . . . . . . . .104 12.5。 UTF-8は.12.6を発行します。 能力のキャッシュは.10613を記載します。 承認. . . . . . . . . . . . . . . . . . . . . .107 14。 参照. . . . . . . . . . . . . . . . . . . . . . . . .110 14.1。 引用規格. . . . . . . . . . . . . . . . . .110 14.2。 有益な参照… 他の仕様. . . . . . . . . . . .112A.1との.110A.相互作用。 ヘッダーの折り重な. . . . . . . . . . . . . . . . . . . . .112りA.2。 メッセージID… .112 A.3。 D.がRFC977から変える応答コード. . . . . . . . . . . . . . . . . .117のコマンド. . . . . . . . . . . . . . . . . . . . .115C.概要の記事任命. . . . . . . . . . . . . . . . . . . . .114B.概要… .121
1. Introduction
1. 序論
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
このドキュメントはネットワークの電子情報を転送するプロトコル(NNTP)を指定します。(それは、Netnews記事の分配、問い合せ、検索、および任命に信頼できる流れのベースのメカニズムを使用することで使用されます)。 ニュースを閲読するクライアントに関してはNNTPがニュース記事の検索を可能にする、それ
Feather Standards Track [Page 3] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[3ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
are stored in a central database, giving subscribers the ability to select only those articles they wish to read.
主要なデータベースでは、それらが読みたがっているそれらの記事だけを選択する能力を加入者に与えて、格納されます。
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.
Netnewsモデルは老いているメッセージのインデックス、十字参照箇所、および満了に備えます。 NNTPはNetnews記事の効率的な伝達のために高信頼の全二重通信チャンネルの上に設計されています。
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:
プロトコル仕様は本書ではRFC977[RFC977]で指定されるバージョンと主に互換性がありますが、Appendix D.Inで特定の状態で多くの変化について略言します:
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 デフォルト文字の組は米国-ASCII[ANSI1986]からUTF-8[RFC3629]に変わります(米国-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 RFC977で任意であったか、またはRFC2980[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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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".
1つか以上を満たさないなら実現が対応でない、このプロトコルのための要件はそうしなければなりません。 そして、すべてを満たす実現、プロトコルのためのすべてのSHOULD要件が「無条件に言いなりになる」と言われています;でなければならない すべてを満たすもの、NNTPのためのすべてのSHOULD要件だけが「条件付きに言いなりになる」と言われているというわけではないという要件はそうしなければなりません。
For the remainder of this document, the terms "client" and "client host" refer to a host making use of the NNTP service, while the terms "server" and "server host" refer to a host that offers the NNTP service.
このドキュメントの残りについて、用語「クライアント」と「クライアントホスト」はNNTPサービスを利用するホストについて言及します、用語「サーバ」と「サーバー・ホスト」はNNTPサービスを提供するホストについて言及しますが。
1.1. Author's Note
1.1. 著者注
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に書かれています。 カスタムソフトウェアは、テキスト、nroffソース、およびHTMLにこれをさらに減少させるためにRFC2629[RFC2629]形式へのこれを変換して、次に、公共の"xml2rfc"パッケージを変換するのに使用されます。
No perl was used in producing this document.
パールは全くこのドキュメントを製作する際に使用されませんでした。
Feather Standards Track [Page 4] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[4ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
2. Notation
2. 記法
The following notational conventions are used in this document.
以下の記号法のコンベンションは本書では使用されます。
UPPERCASE indicates literal text to be included in the
command.
UPPERCASEは、コマンドに含まれるように文字通りのテキストを示します。
lowercase indicates a token described elsewhere.
小文字で印刷してください。説明されて、ほかの場所で象徴を示します。
[brackets] indicate that the enclosed material is optional.
[括弧]は、同封の材料が任意であることを示します。
elliptical indicates that the argument may be repeated any
... marks number of times (it must occur at least once).
楕円、議論は繰り返されたいずれであるかもしれませんも… 回数をマークするのを示します(それは少なくとも一度起こらなければなりません)。
vertical|bar indicates a choice of two mutually exclusive
arguments (exactly one must be provided).
垂直|バーは2つの互いに排他的な議論の選択を示します(ちょうど提供しなければなりません)。
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.
コマンドか応答議論のための名前「メッセージイド」は、それがセクション3.6で説明されるように記事のメッセージイドであることを示します、角ブラケットを含んでいて。
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で定義されるようにwildmatであることを示します。 議論がそのセクションに関する必要条件を満たさないなら(例えばセクション4.1の文法に合わないなら)、NNTPサーバは、何らかの解釈をそれに置かなければならないかもしれないか(このドキュメントで、指定されません)、またはそうでなければ、構文エラーとしてそれを扱わなければなりません。
Responses for each command will be described in tables listing the required format of a response followed by the meaning that should be ascribed to that response.
各コマンドのための応答はその応答のせいにされるべきである意味があとに続いた応答の必要な書式を記載するテーブルで説明されるでしょう。
The terms "NUL", "TAB", "LF", "CR, and "space" refer to the octets %x00, %x09, %x0A, %x0D, and %x20, respectively (that is, the octets with those codes in US-ASCII [ANSI1986] and thus in UTF-8 [RFC3629]). The term "CRLF" or "CRLF pair" means the sequence CR immediately followed by LF (that is, %x0D.0A). A "printable US-ASCII character" is an octet in the range %x21-7E. Quoted characters refer to the octets with those codes in US-ASCII (so "." and "<" refer to %x2E and %x3C) and will always be printable US-ASCII characters; similarly, "digit" refers to the octets %x30-39.
"LF"という用語"NUL"、「タブ」、「CR、および「スペース」は八重奏%x00、%x09、%x0A、%x0D、および%x20を示します、それぞれ(すなわち、その結果、それらのコードが米国-ASCII[ANSI1986]とUTF-8[RFC3629]にある八重奏)。」 "CRLF"か「CRLF組」という用語はすぐにLFによって続かれた系列CRを意味します。(すなわち、%x0D.0A)。 「印刷可能な米国-ASCII文字」は範囲%でx21-7E八重奏です。 「引用されたキャラクタは、米国-ASCII(%x2Eと%x3Cは、」 . 」 そのように、"<"と言及する)におけるそれらのコードで八重奏について言及して、いつも印刷可能な米国-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.
「キーワード」が米国-ASCII手紙、ケタ、およびキャラクタドットだけから成らなければならない、(「」、)、そして、(「-」)と必須が手紙で始めるダッシュ。 キーワードは長さが少なくとも3つのキャラクタであるに違いありません。
Feather Standards Track [Page 5] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[5ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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.
クライアントかサーバ実現の「データベース」などの詳細を指定すると読まれるかもしれない用語は、単に記述を緩和するのに使用されます。 実現が本書ではプロトコルと書式仕様に従えば、どんな特定のテクニックも強制されません。
3. Basic Concepts
3. 基本概念
3.1. Commands and Responses
3.1. コマンドと応答
NNTP operates over any reliable bi-directional 8-bit-wide data stream channel. When the connection is established, the NNTP server host MUST send a greeting. The client host and server host then exchange commands and responses (respectively) until the connection is closed or aborted. If the connection used is TCP, then the server host starts the NNTP service by listening on a TCP port. When a client host wishes to make use of the service, it MUST establish a TCP connection with the server host by connecting to that host on the same port on which the server is listening.
NNTPはどんな高信頼の双方向の幅8ビットのデータストリーム・チャンネルの上でも作動します。 接続が確立されるとき、NNTPサーバー・ホストは挨拶を送らなければなりません。 そして、接続が閉店するか、または中止されるまで、クライアントホストとサーバー・ホストはコマンドと応答(それぞれ)を交換します。 使用される接続がTCPであるなら、サーバー・ホストは、TCPポートの上で聴くことによって、NNTPサービスを始めます。 クライアントホストがサービスを利用したがっているとき、それは、サーバが聴かれているのと同じポートでそのホストに接することによって、サーバー・ホストとのTCP接続を確立しなければなりません。
The character set for all NNTP commands is UTF-8 [RFC3629]. Commands in NNTP MUST consist of a keyword, which MAY be followed by one or more arguments. A CRLF pair MUST terminate all commands. Multiple commands MUST NOT be on the same line. Unless otherwise noted elsewhere in this document, arguments SHOULD consist of printable US- ASCII characters. Keywords and arguments MUST each be separated by one or more space or TAB characters. Command lines MUST NOT exceed 512 octets, which includes the terminating CRLF pair. The arguments MUST NOT exceed 497 octets. A server MAY relax these limits for commands defined in an extension.
すべてのNNTPコマンドのための文字の組はUTF-8[RFC3629]です。 NNTP MUSTのコマンドはキーワードから成ります。(1つ以上の議論がそれのあとに続くかもしれません)。 CRLF組はすべてのコマンドを終えなければなりません。 同じ線の上に複数のコマンドがあるはずがありません。 別の方法でほかの場所に本書では述べられない場合、議論SHOULDは印刷可能な米国のASCII文字から成ります。 1つ以上のスペースかTABキャラクタがそれぞれキーワードと議論を切り離さなければなりません。 コマンドラインは512の八重奏を超えてはいけません(終わっているCRLF組を含んでいます)。 議論は497の八重奏を超えてはいけません。 サーバは拡大で定義されたコマンドのためのこれらの限界を弛緩するかもしれません。
Where this specification permits UTF-8 characters outside the range of U+0000 to U+007F, implementations MUST NOT use the Byte Order Mark (U+FEFF, encoding %xEF.BB.BF) and MUST use the Word Joiner (U+2060, encoding %xE2.91.A0) for the meaning Zero Width No-Break Space in
この仕様がU+0000の範囲の外でU+007FにUTF-8キャラクタを可能にして、どこで、実現は、Byte Orderマーク(%xEF.BB.BFをコード化するU+FEFF)を使用してはいけなくて、意味Zero Width中断がないSpaceに、Word Joiner(%xE2.91.A0をコード化するU+2060)を使用しなければなりませんか。
Feather Standards Track [Page 6] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[6ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
command lines and the initial lines of responses. Implementations SHOULD apply these same principles throughout.
コマンドラインと応答の始線。 SHOULDがこれらの同じ原則を適用する実現。
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.
「キャラクタ」という用語は1つのユニコードコード・ポイントを意味します。 実現は、ユニコード正常化を行うのに必要ではありません。 したがって、U+0084(A-分切)はあるキャラクタですが、U+0041U+0308(分切で構成された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".
コマンドには、異形があるかもしれません。 そうだとすれば、彼らはどの異形が必要であるかを示す1日直後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).
いくつかの場合、コマンドはまさしく単線より多くのデータにかかわります。 詳しいデータは、コマンドライン直後送るか(この仕様にはこの例が全くありませんが、[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ケタの応答コードから始まらなければなりません。 ある有効回答はマルチ線であるために定義されます。 すべての他のものにとって、応答は単線に含まれています。 応答の始線は512の八重奏、どれが応答コードを含むか、そして、および終わっているCRLF組を超えてはいけません。 拡大は、それが定義するコマンドによりすばらしい最大を指定しますが、いかなる他のコマンドのためにも指定するかもしれないというわけではありません。 単線応答は始線だけから成ります。 マルチ線応答はマルチ線データ・ブロックが支えた始線から成ります。
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サーバには、不活発自動ログアウト・タイマーがあるかもしれません。 そのようなタイマSHOULDは少なくとも3分の持続時間のそうです、サーバがどれくらい長いかにおけるより短い限界が、クライアントから最初のコマンドを待っても構わないと思っていたならそれがそこでそうするかもしれない例外で。 SHOULDが自動ログアウト・タイマーをリセットするために満足させるタイマ間隔の間のクライアントからのどんなコマンドの領収書。 同様に、SHOULDが十分であるマルチ線データ・ブロック(ポストやIHAVEコマンドなどの)を送るクライアントからのどんな重要なデータ量の領収書も自動ログアウト・タイマーをリセットしました。 タイマが期限が切れると、どんな応答もクライアントに送らないで、サーバSHOULDは接続を終えます。
Feather Standards Track [Page 7] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[7ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
3.1.1. Multi-line Data Blocks
3.1.1. マルチ線データ・ブロック
A multi-line data block is used in certain commands and responses. It MUST adhere to the following rules:
マルチ線データ・ブロックはあるコマンドと応答に使用されます。 それは以下の規則を固く守らなければなりません:
1. The block consists of a sequence of zero or more "lines", each
being a stream of octets ending with a CRLF pair. Apart from
those line endings, the stream MUST NOT include the octets NUL,
LF, or CR.
1. ブロックがゼロの系列から成るか、または以上は「立ち並んでいます」、それぞれCRLF組と共に終わる八重奏の流れであり。 それらの線結末は別として、流れは八重奏のNUL、LF、またはCRを含んではいけません。
2. In a multi-line response, the block immediately follows the CRLF
at the end of the initial line of the response. When used in any
other context, the specific command will define when the block is
sent.
2. マルチ線応答では、ブロックはすぐに、応答の始線の端でCRLFに続きます。 いかなる他の文脈でも使用されると、特定のコマンドは、ブロックがいつ送られるかを定義するでしょう。
3. If any line of the data block begins with the "termination octet"
("." or %x2E), that line MUST be "dot-stuffed" by prepending an
additional termination octet to that line of the block.
3. 何かデータ・ブロックの線が「終了八重奏」で始まる、(「. 」 %x2E、)、その線は、ブロックのその線に追加終了八重奏をprependingすることによって、「ドットで、詰められなければなりません」。
4. The lines of the block MUST be followed by a terminating line
consisting of a single termination octet followed by a CRLF pair
in the normal way. Thus, unless it is empty, a multi-line block
is always terminated with the five octets CRLF "." CRLF
(%x0D.0A.2E.0D.0A).
4. CRLF組によって正常な方法で後をつけられたただ一つの終了八重奏から成る終わり線はブロックの線を支えなければなりません。 「その結果、それが空でない場合、aマルチ線画凸版は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組以外の八重奏が終了八重奏のあとに続いていて始まるどんな線でも無視されるのを保証しなければなりません。
6. Likewise, the terminating line ("." CRLF or %x2E.0D.0A) MUST NOT
be considered part of the multi-line block; i.e., the recipient
MUST ensure that any line beginning with the termination octet
followed immediately by a CRLF pair is disregarded. (The first
CRLF pair of the terminating CRLF "." CRLF of a non-empty block
is, of course, part of the last line of the block.)
6. 同様に終わり線、(「. 」 マルチ線画凸版の一部であるとCRLFか%x2E.0D.0A)を考えてはいけません。 すなわち、受取人は、終了八重奏がすぐCRLF組によって後をつけられている状態で始まるどんな線も無視されるのを保証しなければなりません。 最初のCRLFは対にします。「(終わりCRLFでは、」 . 」 1つの非空きブロックの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.
上の形式で八重奏のNUL、LF、またはCRLF組以外のCRを含むかもしれないコード化(UTF-16かUTF-32などの)を使用するテキストは確かに伝えることができないことに注意してください。(それがそう、それらが違反する、上記の要件)でなければならない しかしながら、別の方法で述べられている時以外に、この仕様は、内容がUTF-8であることを必要としません、そして、したがって(その同じ要件を受けることがある)、上の八重奏を含むかもしれません、そして、128未満は任意に混入しました。
This document does not place any limit on the length of a line in a multi-line block. However, the standards that define the format of articles may do so.
このドキュメントはマルチ線画凸版の線の長さにどんな限界も置きません。 しかしながら、記事の書式を定義する規格はそうするかもしれません。
Feather Standards Track [Page 8] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[8ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
3.2. Response Codes
3.2. 応答コード
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--コマンドはOK3xxを完成しました--今までのところのCommand 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.
ある応答は自動運転表示灯に加えた数や名前などの議論を含んでいます。 それらの場合では、そのような議論のクライアント、数、およびタイプによる解釈を簡素化するのはそれぞれの応答コードのために修理されています、コードが単線であるか、そして、マルチ線のように。 どんな拡大もまた、この原則に従わなければなりません。 それを発生させたコマンド(GROUPかLISTGROUP)によって、応答がただ一つの線かマルチ線であるかもしれないことによって211応答コードがこれへの歴史的な理由に関する例外であることに注意してください。 他のすべての場合では、クライアントは、応答の本質を決定するのに自動運転表示灯自体を使用するだけでよいです。 どんな与えられたコマンドでも返すことができる正確な応答コードはそのコマンドの記述で詳細です。
Arguments MUST be separated from the numeric status indicator and from each other by a single space. All numeric arguments MUST be in base 10 (decimal) format and MAY have leading zeros. String arguments MUST contain at least one character and MUST NOT contain TAB, LF, CR, or space. The server MAY add any text after the response code or last argument, as appropriate, and the client MUST NOT make decisions based on this text. Such text MUST be separated from the numeric status indicator or the last argument by at least one space.
数値自動運転表示灯とシングルスペースのそばの互いと議論を切り離さなければなりません。 すべての数値議論には、ベース10(10進)形式にあるに違いなくて、先行ゼロがあるかもしれません。 ストリング議論は、少なくとも1文字を含まなければならなくて、TAB、LF、CR、またはスペースは含んではいけません。 サーバは、応答コードの後にどんなテキストも加えるか、または適宜議論が続くかもしれません、そして、クライアントは本稿に基づく決定をしてはいけません。 数値自動運転表示灯か最後の議論と少なくとも1つのスペースでそのようなテキストを切り離さなければなりません。
Feather Standards Track [Page 9] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[9ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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では、与える)でどんなコマンドにも反応しなければなりません。 さもなければ、それぞれが、コマンドが記述か拡大で明確に記載された応答コードの1つを返さなければならないと認めました。 サーバはこの仕様に拡大を提供するかもしれません、既存のコマンド、およびサーバの内部の事情を変える他の方法の新しいコマンド、新しい変種または特徴を含んでいて。しかしながら、サーバは付加的な機能のいずれも呼び出さないクライアントへのいかなる他の応答も起こしてはいけません。 (したがって、それ自体をこの仕様に制限するクライアントは記載された応答を受けるだけでしょう。)
If a client receives an unexpected response, it SHOULD use the first digit of the response to determine the result. For example, an unexpected 2xx should be taken as success, and an unexpected 4xx or 5xx as failure.
クライアントはaであるなら予期していなかった応答を受けて、それは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.
コードが指定しなかった応答はまた、指定されなかった少しのインストール特有の追加コマンドにも本書では使用されるかもしれません。 これらのSHOULD、選ばれて、上で指定された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パターンの少しの応答コードも指定しないでしょう。 (拡大のImplementersが次に登録のために提出されるかもしれない拡大にそのような応答を使用しないとそれに従って、警告されます。)
3.2.1. Generic Response Codes
3.2.1. ジェネリック応答コード
The server MUST respond to any command with the appropriate one of the following generic responses if it represents the situation.
状況を表すなら、サーバは以下のジェネリック応答の適切な1つでどんなコマンドにも反応しなければなりません。
If the command is not recognized, or if it is an optional command that is not implemented by the server, the response code 500 MUST be returned.
コマンドが認識されないか、またはそれがサーバによって実装されない、任意のコマンドであるなら、応答コード500を返さなければなりません。
If there is a syntax error in the arguments of a recognized command, including the case where more arguments are provided than the command specifies or the command line is longer than the server accepts, the response code 501 MUST be returned. The line MUST NOT be truncated or split and then interpreted. Note that where a command has variants depending on a second keyword (e.g., LIST ACTIVE and LIST NEWSGROUPS), 501 MUST be used when the base command is implemented but the requested variant is not, and 500 MUST be used only when the base command itself is not implemented.
認識されたコマンドの議論には構文エラーがあります、と、より多くの議論がコマンドより提供されるケースを含んでいるのが指定するか、またはコマンドラインがサーバが受け入れるより長いなら、応答コード501を返さなければなりません。 系列を、先端を切ってはいけないか、分けられて、次に、解釈してはいけません。 ベースコマンド自体が実装されないときだけ、異形がコマンドで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
議論がbase64によってコード化されたストリング[RFC4648]になるのに必要である、(あるかもしれないそのような議論でないのがあります。
Feather Standards Track [Page 10] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[10ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
in extensions) and is not validly encoded, the response code 504 MUST be returned.
中、拡大)、確実にコード化されていなくて、応答コード504を返さなければならないということです。
If the server experiences an internal fault or problem that means it is unable to carry out the command (for example, a necessary file is missing or a necessary service could not be contacted), the response code 403 MUST be returned. If the server recognizes the command but does not provide an optional feature (for example, because it does not store the required information), or if it only handles a subset of legitimate cases (see the HDR command, Section 8.5, for an example), the response code 503 MUST be returned.
サーバがコマンドを実行できないことを(例えば、必要なファイルがなくなるか、または必要なサービスに連絡できませんでした)意味する内部の欠点か問題になるなら、応答コード403を返さなければなりません。 サーバがコマンドを認識しますが、オプション機能を提供しないか(例えば必須情報を保存しないので)、または正統のケースの部分集合を扱うだけであるなら(HDRコマンドを見てください、セクション8.5、例のために)、応答コード503を返さなければなりません。
If the client is not authorized to use the specified facility when the server is in its current state, then the appropriate one of the following response codes MUST be used.
現状のときに、サーバがあるとき、クライアントが指定された施設を使用するのに権限を与えられないなら、以下の応答コードの適切な1つを使用しなければなりません。
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)が使用されていた後にこのコマンドが利用可能になりますが、この用法がこの仕様に従わないで、使用されてはいけないのを示すのにこの応答を使用しました。 サーバが502応答直後初期の接続(セクション5.1)においてMODE READERコマンドで接続を終えてはいけないことに注意してください。
480: The client must authenticate itself to the server (that is, it
must provide information as to the identity of the client) before
the facility can be used on this connection. This will involve
the use of an authentication extension such as [NNTP-AUTH].
480: この接続のときに施設を使用できる前にクライアントはサーバ(すなわち、それはクライアントのアイデンティティに関して情報を提供しなければならない)にそれ自体を認証しなければなりません。 これは[NNTP-AUTH]などの認証拡張子の使用にかかわるでしょう。
483: The client must negotiate appropriate privacy protection on the
connection. This will involve the use of a privacy extension such
as [NNTP-TLS].
483: クライアントは接続に関して適切なプライバシー保護を交渉しなければなりません。 これは[NNTP-TLS]などのプライバシー拡張子の使用にかかわるでしょう。
401: The client must change the state of the connection in some other
manner. The first argument of the response MUST be the capability
label (see Section 5.2) of the facility that provides the
necessary mechanism (usually an extension, which may be a private
extension). The server MUST NOT use this response code except as
specified by the definition of the capability in question.
401: クライアントはある他の方法で接続の状態を変えなければなりません。 応答の最初の議論は必要なメカニズム(通常個人的な拡大であるかもしれない拡大)を提供する施設の能力ラベルであるに違いありません(セクション5.2を見ます)。 問題の能力の定義で指定される以外に、サーバはこの応答コードを使用してはいけません。
If the server has to terminate the connection for some reason, it MUST give a 400 response code to the next command and then immediately close the connection. Following a 400 response, clients SHOULD NOT simply reconnect immediately and retry the same actions. Rather, a client SHOULD either use an exponentially increasing delay between retries (e.g., double the waiting time after each 400
サーバがある理由で接続を終えなければならないなら、それは、400応答コードを次のコマンドに与えて、すぐに、接続を終えなければなりません。 400応答に続いて、クライアントSHOULD NOTは単に同じ動作をすぐに、再接続して、再試行します。 むしろ、aクライアントSHOULDが再試行の間の指数関数的に増加する遅れを使用する、(例えば、各400の後に待ち時間を倍にしてください。
Feather Standards Track [Page 11] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[11ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
response) or present any associated text to the user for them to decide whether and when to retry.
応答) または、彼らが再試行していつ再試行するかを決めるユーザへの現在のいずれも関連しているテキスト。
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応答がコードであると生成してはいけません)
3.2.1.1. Examples
3.2.1.1. 例
Example of an unknown command:
未知のコマンドに関する例:
[C] MAIL
[S] 500 Unknown command
[C] メール[S]500Unknownコマンド
Example of an unsupported command:
サポートされないコマンドに関する例:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] NEWNEWS
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] OVER
[S] 500 Unknown command
[C] CAPABILITIES[S]101Capabilityは記載します: [S]バージョン2[S]読者[S]NEWNEWS[S]LIST ACTIVE NEWSGROUPS[S][C]OVER[S]500Unknownコマンド
Example of an unsupported variant:
サポートされない異形に関する例:
[C] MODE POSTER
[S] 501 Unknown MODE option
[C]MODE POSTER[S]501Unknown 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]501Syntax誤り
Example of an overlong command line:
余りにも長いコマンドラインに関する例:
[C] HEAD 53 54 55
[S] 501 Too many arguments
[C] HEAD53 54 55[S]501Too多くの議論
Example of a bad wildmat:
悪いwildmatに関する例:
[C] LIST ACTIVE u[ks].*
[S] 501 Syntax error
[C]LIST ACTIVE u[ks] *[S]501Syntax誤り
Feather Standards Track [Page 12] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[12ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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]504Base64
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] IHAVE <i.am.an.article.you.will.want@example.com を掲示する[C]MODE READER[S]200読者モード、gt;、[S]500Permissionは否定しました。
Example of an attempt to access a facility requiring authentication:
認証を必要とする施設にアクセスする試みに関する例:
[C] GROUP secret.group
[S] 480 Permission denied
Permissionが否定した[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] fredのためのXSECRET fred flintstone[S]290Passwordは20secret.groupが選択した[C]GROUP secret.group[S]211 5 1を受け入れました。
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のSecureの接続の必要な[C]XENCRYPT[クライアントとサーバはリンクに関して暗号化を交渉する][S]283Encryptedリンクは20secret.groupが選択した[C]GROUP secret.group[S]211 5 1を確立しました。
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] この仮想のホスト[C]XHOST binary.news.example.org[S]290のbinary.news.example.orgの事実上のホストの上のGROUP binary.group[S]401XHOST Notは77binary.groupが選択した[C]GROUP binary.group[S]211 5 1を選択しました。
Feather Standards Track [Page 13] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[13ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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] UPSの上で作業して、ARTICLE123[S]400Power供給は失敗しました。[サーバは接続を終えます。]
3.3. Capabilities and Extensions
3.3. 能力と拡大
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サーバがまさに同じ施設を提供するというわけではありません、この仕様がともに変化を許容して、サーバが拡大を提供するかもしれないので。 関係づけられる1セットの施設は「能力」と呼ばれます。 この仕様は、どんな能力が利用可能であるかを決定する方法を提供して、標準の能力のリストを含んでいて、新しい能力を定義するためのメカニズム(拡張機能)を含んでいます。
3.3.1. Capability Descriptions
3.3.1. 能力記述
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つ以上のスペースかTABキャラクタがトークンを切り離さなければなりません)。 トークンは、一連の1か、より印刷可能なUTF-8キャラクタ(すなわち、スペースではなく、印刷可能な米国-ASCII文字か米国の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
サーバは、ケイパビリティ・リストが正確に、現在利用可能な能力(拡大を含んでいる)を反映するのを確実にしなければなりません。 状態(例えば認証の後にだけ)、リストがそうしなければならないのを確信しているaが含んでいるだけである状態で、能力は中のサーバが利用可能であるだけです。
Feather Standards Track [Page 14] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[14ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
capability label when the server is in that state. Similarly, if only some of the commands in an extension will be available, or if the behaviour of the extension will change in some other manner, according to the state of the server, this MUST be indicated by different arguments in the capability line.
サーバであるときに、能力ラベルがその状態にあります。 同様に、拡大におけるコマンドのいくつかだけが利用可能になるか、またはサーバの事情に応じて拡大のふるまいがある他の方法で変化するなら、能力系列における異なった議論でこれを示さなければなりません。
Note that a capability line can only begin with a letter. Lines beginning with other characters are reserved for future versions of this specification. In order to interoperate with such versions, clients MUST be prepared to receive lines beginning with other characters and MUST ignore any they do not understand.
能力系列が手紙で始まることができるだけであることに注意してください。 他のキャラクタと共に始まる線はこの仕様の将来のバージョンのために予約されます。 クライアントは、そのようなバージョンで共同利用するために他のキャラクタと共に始まりながら台詞を受けるように準備しなければならなくて、いずれも無視しなければなりません。彼らは分かりません。
3.3.2. Standard Capabilities
3.3.2. 標準の能力
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.
バージョンThis能力は、すべてのサーバで広告を出さなければならなくて、ケイパビリティ・リストで最初の能力であるに違いありません。 それはサーバがサポートするNNTPのバージョンを示します。 少なくとも1つの議論があるに違いありません。 各議論は、10進数であり、先行ゼロを持ってはいけません。 バージョン番号はこの仕様をアップデートするか、または置き換えるRFCsだけで割り当てられます。 サーバはそれら自身のバージョン番号を作成してはいけません。
The version number of this specification is 2.
この仕様のバージョン番号は2です。
READER
This capability indicates that the server implements the various
commands useful for reading clients.
読者This能力は、サーバが読書クライアントの役に立つ様々なコマンドを実装するのを示します。
IHAVE
This capability indicates that the server implements the IHAVE
command.
IHAVE This能力は、サーバが、IHAVEがコマンドであると実装するのを示します。
POST
This capability indicates that the server implements the POST
command.
ポストThis能力は、サーバがポストコマンドを実装するのを示します。
NEWNEWS
This capability indicates that the server implements the NEWNEWS
command.
NEWNEWS This能力は、サーバが、NEWNEWSがコマンドであると実装するのを示します。
HDR
This capability indicates that the server implements the header
access commands (HDR and LIST HEADERS).
HDR This能力は、サーバが、ヘッダーアクセスがコマンド(HDRとLIST HEADERS)であると実装するのを示します。
Feather Standards Track [Page 15] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[15ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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 This能力は、サーバが、概要アクセスがコマンド(OVERとLIST OVERVIEW.FMT)であると実装するのを示します。 OVERのメッセージイドフォームがそこで命令するサーバサポートがそうしなければならない場合にだけ、aただ一つの議論MSGIDはそうです。
LIST
This capability indicates that the server implements at least one
variant of the LIST command. There MUST be one argument for each
variant of the LIST command supported by the server, giving the
keyword for that variant.
LIST This能力は、サーバが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.)
そうだとすれば、サーバでIMPLEMENTATION This能力を提供するかもしれない、議論SHOULD、使用されて、サーバソフト名やバージョン番号の情報を提供してください。 クライアントは、サーバの能力を決定するのにこの系列を使用してはいけません。(サーバがしばしばこの情報を初期の挨拶に提供している間、クライアントは、これがそうであるかどうか推測する必要があります; この能力は、情報が何であるかを断言します。)
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-読者This能力は、サーバがモード切り換えであり(セクション3.4.2)、MODE READERコマンドが、読者能力を可能にするのに使用される必要であるのを示します。
3.3.3. Extensions
3.3.3. 拡大
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
拡大はいつもでない、しかし、しばしば1つ以上の新しいコマンドを含む関連施設のパッケージです。 各拡大は少なくとも1個の新しい能力ラベルを定義しなければなりません。しかし、(これがしばしばそうする、これらの新しいコマンドの1つの名前になってください、)でなければならない 通常、議論を使用することでどんな追加能力情報も指定できます。
Feather Standards Track [Page 16] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[16ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
that label, an extension MAY define more than one capability label. However, this SHOULD be limited to exceptional circumstances.
そのラベル、拡大は1個以上の能力ラベルを定義するかもしれません。 しかしながら、このSHOULD、例外的な事情に制限されてください。
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で定義されます(その場合、それは「登録された拡大」です)。 そのようなRFCsは標準化過程の上になければならないに違いないか、または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応答を起こすどんな先在のコマンドも引き起こす場合がある事情に関する特定の声明。
Feather Standards Track [Page 17] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[17ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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」と共に始まらなければなりません。 サーバは個人的な拡大の一部として追加キーワード(新しいコマンドと既存のコマンドの新しい変種のためにも)を提供するかもしれません。 今後の登録された拡大、これらのキーワードとの衝突の危険を避けるために、SHOULDは「X」と共に始まります。
If the server advertises a capability defined by a registered extension, it MUST implement the extension so as to fully conform with the specification (for example, it MUST implement all the commands that the extension describes as mandatory). If it does not implement the extension as specified, it MUST NOT list the extension in the capabilities list under its registered name. In that case, it MAY, but SHOULD NOT, provide a private extension (not listed, or listed with a different name) that implements part of the extension or implements the commands of the extension with a different meaning.
サーバが登録された拡大で定義された能力の広告を出すなら、それは、仕様に完全に従うために拡大を実装しなければなりません(例えば、それは拡大が義務的であると説明するすべてのコマンドを実装しなければなりません)。 指定されるとして拡大を実装しないなら、それは登録名の下で能力リストにおける拡大を記載してはいけません。 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コマンド、または、登録された拡大に記録されたコマンドに異なった応答コードを送ってはいけません。
3.3.4. Initial IANA Register
3.3.4. 初期のIANAは登録します。
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と共に始まらなければならないというわけではありません。
Feather Standards Track [Page 18] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[18ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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 | +-------------------+--------------------------+--------------------+
+-------------------+--------------------------+--------------------+ | ラベル| 意味| 定義| +-------------------+--------------------------+--------------------+ | AUTHINFO| 認証| [NNTP-AUTH]| | | | | | HDR| ヘッダー検索をBatchedしました。| セクション3.3.2| | | | そしてセクション8.5。| | | | セクション8.6| | | | | | IHAVE| 利用可能なIHAVEコマンド| そしてセクション3.3.2。| | | | セクション6.3 .2| | | | | | 実装| サーバ| セクション3.3 .2| | | 実装特有です。| | | | 情報| | | | | | | リスト| LISTコマンド異形| そしてセクション3.3.2。| | | | セクション7.6 .1| | | | | | モード読者| モードを切り換えるサーバ| セクション3.4 .2| | | そして、MODE READERは命令します。| | | | 利用可能| | | | | | | NEWNEWS| NEWNEWSコマンド| そしてセクション3.3.2。| | | 利用可能| セクション7.4| | | | | | 終わる| 概要サポート| セクション3.3.2| | | | そしてセクション8.3。| | | | セクション8.4| | | | | | ポスト| 利用可能なポストコマンド| そしてセクション3.3.2。| | | | セクション6.3 .1| | | | | | 読者| 読者コマンド| セクション3.3 .2| | | 利用可能| | | | | | | SASL| SASLであるとサポートされます。| [NNTP-AUTH]| | | メカニズム| | | | | | | STARTTLS| トランスポート層セキュリティ| [NNTP-TLS]| | | | | | ストリーミング| ストリーミングの給送| [NNTP-ストリーム]| | | | | | バージョン| NNTPバージョンであるとサポートされます。| セクション3.3 .2| +-------------------+--------------------------+--------------------+
Feather Standards Track [Page 19] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[19ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
3.4. Mandatory and Optional Commands
3.4. 義務的で任意のコマンド
For a number of reasons, not all the commands in this specification are mandatory. However, it is equally undesirable for every command to be optional, since this means that a client will have no idea what facilities are available. Therefore, as a compromise, some of the commands in this specification are mandatory (they must be supported by all servers) while the remainder are not. The latter are then subdivided into bundles, each indicated by a single capability label.
様々な意味ですべてではなく、この仕様に基づくコマンドは義務的です。 しかしながら、任意になるあらゆるコマンドには、それは等しく望ましくありません、これが、クライアントが、どんな施設が利用可能であるかが分からないことを意味するので。 したがって、残りは義務的ではありませんが、感染として、この仕様に基づくコマンドのいくつかが義務的です(すべてのサーバでそれらをサポートしなければなりません)。 それぞれが、単一の能力ラベルで次に、後者がバンドルに細分されるのを示しました。
o If the label is included in the capability list returned by the
server, the server MUST support all commands in that bundle.
o ラベルがサーバによって返されたケイパビリティ・リストに含まれているなら、サーバはそのバンドルですべてのコマンドをサポートしなければなりません。
o If the label is not included, the server MAY support none or some
of the commands but SHOULD NOT support all of them. In general,
there will be no way for a client to determine which commands are
supported without trying them.
o ラベルが含まれていないなら、サーバはコマンドのなにもかいくつかをサポートするかもしれませんが、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ジェネリック応答コード)であると生成しなければなりません。 さもなければ、指定されるとしてコマンドを完全に実装しなければなりません。 サーバはこの仕様でコマンドのいずれも部分的に実装するだけでよくはありません。 (クライアント作者は、この仕様に従わないいくつかのサーバが502ジェネリック応答コードを実装されないいくつかのコマンドに返すことに注意するべきです。)
Note: some commands have cases that require other commands to be used first. If the former command is implemented but the latter is not, the former MUST still generate the relevant specific response code. For example, if ARTICLE (Section 6.2.1) is implemented but GROUP (Section 6.1.1) is not, the correct response to "ARTICLE 1234" remains 412.
以下に注意してください。 いくつかのコマンドには、他の最初に使用されるべきコマンドを必要とするケースがあります。 前のコマンドが実装されますが、後者が実装されるというわけではないなら、前者はまだ関連特定の応答コードを生成しなければなりません。 例えば、ARTICLE(セクション6.2.1)が実装されますが、GROUP(セクション6.1.1)が実装されるというわけではないなら、「第1234条」への正しい応答は412のままで残っています。
Feather Standards Track [Page 20] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 20] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
3.4.1. Reading and Transit Servers
3.4.1. Reading and Transit Servers
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 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).
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.
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.
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.
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.
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.
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.
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.
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.
3.4.2. Mode Switching
3.4.2. Mode Switching
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.
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.
Feather Standards Track [Page 21] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 21] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
A mode-switching server has two modes:
A mode-switching server has two modes:
o Transit mode, which applies after the initial connection.
o Transit mode, which applies after the initial connection.
* It MUST advertise the MODE-READER capability.
* It MUST advertise the MODE-READER capability.
* It MUST NOT advertise the READER capability.
* It MUST NOT advertise the READER capability.
However, the server MAY cease to advertise the MODE-READER
capability after the client uses any command except CAPABILITIES.
However, the server MAY cease to advertise the MODE-READER capability after the client uses any command except CAPABILITIES.
o Reading mode, after a successful MODE READER command (see Section
5.3).
o Reading mode, after a successful MODE READER command (see Section 5.3).
* It MUST NOT advertise the MODE-READER capability.
* It MUST NOT advertise the MODE-READER capability.
* It MUST advertise the READER capability.
* It MUST advertise the READER capability.
* It MAY NOT advertise the IHAVE capability, even if it was
advertising it in transit mode.
* It MAY NOT advertise the IHAVE capability, even if it was advertising it in transit mode.
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:
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:
o If the client wishes to use any "reader" commands, it SHOULD use
the MODE READER command immediately after the initial connection.
o If the client wishes to use any "reader" commands, it SHOULD use the MODE READER command immediately after the initial connection.
o Otherwise, it SHOULD NOT use the MODE READER command.
o Otherwise, it SHOULD NOT use the MODE READER command.
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.
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.
3.5. Pipelining
3.5. Pipelining
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
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
Feather Standards Track [Page 22] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 22] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
manner, this document puts certain requirements on both clients and servers.
manner, this document puts certain requirements on both clients and servers.
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.
Except where stated otherwise, a client MAY use pipelining. That is, it may send a command before receiving the response for the previous command. The server MUST allow pipelining and MUST NOT throw away any text received after a command. Irrespective of whether pipelining is used, the server MUST process commands in the order they are sent.
If the specific description of a command says it "MUST NOT be pipelined", that command MUST end any pipeline of commands. That is, the client MUST NOT send any following command until it receives the CRLF at the end of the response from the command. The server MAY ignore any data received after the command and before the CRLF at the end of the response is sent to the client.
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.
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.
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.
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.)
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.)
3.5.1. Examples
3.5.1. Examples
Example of correct use of pipelining:
Example of correct use of pipelining:
[C] GROUP misc.test
[C] STAT
[C] NEXT
[S] 211 1234 3000234 3002322 misc.test
[S] 223 3000234 <45223423@example.com> retrieved
[S] 223 3000237 <668929@example.org> retrieved
[C] GROUP misc.test [C] STAT [C] NEXT [S] 211 1234 3000234 3002322 misc.test [S] 223 3000234 <45223423@example.com> retrieved [S] 223 3000237 <668929@example.org> retrieved
Example of incorrect use of pipelining (the MODE READER command may not be pipelined):
Example of incorrect use of pipelining (the MODE READER command may not be pipelined):
[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 Server ready, posting allowed [S] 223 3000237 <668929@example.org> retrieved
Feather Standards Track [Page 23] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 23] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
The DATE command has been thrown away by the server, so there is no 111 response to match it.
The DATE command has been thrown away by the server, so there is no 111 response to match it.
3.6. Articles
3.6. Articles
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 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.
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.
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.
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.
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.
Feather Standards Track [Page 24] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 24] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
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.
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.
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:
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:
o A message-id MUST begin with "<", end with ">", and MUST NOT
contain the latter except at the end.
o A message-id MUST begin with "<", end with ">", and MUST NOT contain the latter except at the end.
o A message-id MUST be between 3 and 250 octets in length.
o A message-id MUST be between 3 and 250 octets in length.
o A message-id MUST NOT contain octets other than printable US-ASCII
characters.
o A message-id MUST NOT contain octets other than printable US-ASCII characters.
Two message-ids are the same if and only if they consist of the same sequence of octets.
Two message-ids are the same if and only if they consist of the same sequence of octets.
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.
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.
4. The WILDMAT Format
4. The WILDMAT Format
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.
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.
Feather Standards Track [Page 25] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 25] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
4.1. Wildmat Syntax
4.1. Wildmat Syntax
A wildmat is described by the following ABNF [RFC4234] syntax, which is an extract of that in Section 9.8.
A wildmat is described by the following ABNF [RFC4234] syntax, which is an extract of that in Section 9.8.
wildmat = wildmat-pattern *("," ["!"] wildmat-pattern)
wildmat-pattern = 1*wildmat-item
wildmat-item = wildmat-exact / wildmat-wild
wildmat-exact = %x22-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E /
UTF8-non-ascii ; exclude ! * , ? [ \ ]
wildmat-wild = "*" / "?"
wildmat = wildmat-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.
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.
4.2. Wildmat Semantics
4.2. Wildmat Semantics
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.
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.
For example, consider the wildmat "a*,!*b,*c*":
For example, consider the wildmat "a*,!*b,*c*":
o The string "aaa" matches because the rightmost match is with "a*".
o The string "aaa" matches because the rightmost match is with "a*".
o The string "abb" does not match because the rightmost match is
with "*b".
o The string "abb" does not match because the rightmost match is with "*b".
o The string "ccb" matches because the rightmost match is with
"*c*".
o The string "ccb" matches because the rightmost match is with "*c*".
o The string "xxx" does not match because no <wildmat-pattern>
matches.
o The string "xxx" does not match because no <wildmat-pattern> matches.
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
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
Feather Standards Track [Page 26] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 26] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
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).
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).
A <wildmat-exact> matches the same character (which may be more than one octet in UTF-8).
A <wildmat-exact> matches the same character (which may be more than one octet in UTF-8).
"?" matches exactly one character (which may be more than one octet).
"?" matches exactly one character (which may be more than one octet).
"*" 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.
"*" 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.
4.3. Extensions
4.3. Extensions
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.
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.
4.4. Examples
4.4. Examples
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.
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.
Wildmat Description of strings that match
abc The one string "abc"
abc,def The two strings "abc" and "def"
$@ The one character string "#"
a* Any string that begins with "a"
a*b Any string that begins with "a" and ends with "b"
a*,*b Any string that begins with "a" or ends with "b"
a*,!*b Any string that begins with "a" and does not end with
"b"
a*,!*b,c* Any string that begins with "a" and does not end with
"b", and any string that begins with "c" no matter
what it ends with
a*,c*,!*b Any string that begins with "a" or "c" and does not
end with "b"
?a* Any string with "a" as its second character
??a* Any string with "a" as its third character
*a? Any string with "a" as its penultimate character
*a?? Any string with "a" as its antepenultimate character
Wildmat 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
Feather Standards Track [Page 27] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 27] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
5. Session Administration Commands
5. Session Administration Commands
5.1. Initial Connection
5.1. Initial Connection
5.1.1. Usage
5.1.1. Usage
This command MUST NOT be pipelined.
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]
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] These are the only valid response codes for the initial greeting; the server MUST not return any other generic response code.
[2] Following a 400 or 502 response, the server MUST immediately
close the connection.
[2] Following a 400 or 502 response, the server MUST immediately close the connection.
5.1.2. Description
5.1.2. Description
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.
There is no command presented by the client upon initial connection to the server. The server MUST present an appropriate response code as a greeting to the client. This response informs the client whether service is available and whether the client is permitted to post.
If the server will accept further commands from the client including POST, the server MUST present a 200 greeting code. If the server will accept further commands from the client, but the client is not authorized to post articles using the POST command, the server MUST present a 201 greeting code.
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.
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.
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.
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
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
Feather Standards Track [Page 28] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 28] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
the CAPABILITIES command (Section 5.2) rather than rely on this response.
the CAPABILITIES command (Section 5.2) rather than rely on this response.
5.1.3. Examples
5.1.3. Examples
Example of a normal connection from an authorized client that then terminates the session (see Section 5.4):
Example of a normal connection from an authorized client that then terminates the session (see Section 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.]
[Initial connection set-up completed.] [S] 200 NNTP Service Ready, posting permitted [C] QUIT [S] 205 NNTP Service exits normally [Server closes connection.]
Example of a normal connection from an authorized client that is not permitted to post, which also immediately terminates the session:
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.]
[Initial connection set-up completed.] [S] 201 NNTP Service Ready, posting prohibited [C] QUIT [S] 205 NNTP Service exits normally [Server closes connection.]
Example of a normal connection from an unauthorized client:
Example of a normal connection from an unauthorized client:
[Initial connection set-up completed.]
[S] 502 NNTP Service permanently unavailable
[Server closes connection.]
[Initial connection set-up completed.] [S] 502 NNTP Service permanently unavailable [Server closes connection.]
Example of a connection from a client if the server is unable to provide service:
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.]
[Initial connection set-up completed.] [S] 400 NNTP Service temporarily unavailable [Server closes connection.]
5.2. CAPABILITIES
5.2. CAPABILITIES
5.2.1. Usage
5.2.1. Usage
This command is mandatory.
This command is mandatory.
Syntax
CAPABILITIES [keyword]
Syntax CAPABILITIES [keyword]
Responses
101 Capability list follows (multi-line)
Responses 101 Capability list follows (multi-line)
Feather Standards Track [Page 29] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 29] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Parameters
keyword additional feature, see description
Parameters keyword additional feature, see description
5.2.2. Description
5.2.2. Description
The CAPABILITIES command allows a client to determine the capabilities of the server at any given time.
The CAPABILITIES command allows a client to determine the capabilities of the server at any given time.
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.
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.
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.
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.
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.
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.
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
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
Feather Standards Track [Page 30] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 30] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
(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.
(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.
5.2.3. Examples
5.2.3. Examples
Example of a minimal response (a read-only server):
Example of a minimal response (a read-only server):
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS [S] .
Example of a response from a server that has a range of facilities and that also describes itself:
Example of a response from a server that has a range of facilities and that also describes itself:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] POST
[S] NEWNEWS
[S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES OVERVIEW.FMT
[S] IMPLEMENTATION INN 4.2 2004-12-25
[S] OVER MSGID
[S] STREAMING
[S] XSECRET
[S] .
[C] CAPABILITIES [S] 101 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] .
Example of a server that supports more than one version of NNTP:
Example of a server that supports more than one version of NNTP:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2 3
[S] READER
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 3 [S] READER [S] LIST ACTIVE NEWSGROUPS [S] .
Feather Standards Track [Page 31] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 31] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Example of a client attempting to use a feature of the CAPABILITIES command that the server does not support:
Example of a client attempting to use a feature of the CAPABILITIES command that the server does not support:
[C] CAPABILITIES AUTOUPDATE
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT HEADERS
[S] OVER MSGID
[S] HDR
[S] NEWNEWS
[S] .
[C] CAPABILITIES AUTOUPDATE [S] 101 Capability list: [S] VERSION 2 [S] READER [S] IHAVE [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT HEADERS [S] OVER MSGID [S] HDR [S] NEWNEWS [S] .
5.3. MODE READER
5.3. MODE READER
5.3.1. Usage
5.3.1. Usage
Indicating capability: MODE-READER
能力を示します: モード読者
This command MUST NOT be pipelined.
このコマンドをpipelinedしてはいけません。
Syntax
MODE READER
構文モード読者
Responses
200 Posting allowed
201 Posting prohibited
502 Reading service permanently unavailable [1]
201Postingが許容された応答200Postingは永久に入手できない502Readingサービスを禁止しました。[1]
[1] Following a 502 response the server MUST immediately close the
connection.
[1] 502応答に続いて、サーバはすぐに、接続を終えなければなりません。
5.3.2. Description
5.3.2. 記述
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.
サーバがモード切り換えであるなら、トランジットモードから読者モードに切り替わります、それに従って、ケイパビリティ・リストを変えることによってこれを示して。 そして、それは初期の挨拶のように同じ意味がある200か201応答を返さなければなりません(セクション5.1.1で説明されるように)。 応答が初期の挨拶の間に提示されたそれと同じである必要はないことに注意してください。 クライアントがセッションの一度かどんなセキュリティの後よりもMODE READERを発行してはいけない、さもなければ、プライバシーコマンドを発行します。 MODE READERがいつ命令するかは発行されて、サーバ5月のリセットはモードを切り換える前の初期の接続直後それへのその状態です。
Feather Standards Track [Page 32] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[32ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
If the server is not mode-switching, then the following apply:
サーバがモード切り換えでないなら、以下は適用されます:
o If it advertises the READER capability, it MUST return a 200 or
201 response with the same meaning as for the initial greeting; in
this case, the command MUST NOT affect the server state in any
way.
o 読者能力の広告を出すなら、初期の挨拶のように同じ意味がある200か201応答を返さなければなりません。 この場合、コマンドは何らかの方法でサーバ状態に影響してはいけません。
o If it does not advertise the READER capability, it MUST return a
502 response and then immediately close the connection.
o 読者能力の広告を出さないなら、それは、502応答を返して、すぐに、接続を終えなければなりません。
5.3.3. Examples
5.3.3. 例
Example of use of the MODE READER command on a transit-only server (which therefore does not providing reading facilities):
トランジットだけサーバ(したがって、施設を読みながら、提供でないのをする)でMODE READERコマンドで役に立つ例:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] .
[C] MODE READER
[S] 502 Transit service only
[Server closes connection.]
[C] CAPABILITIES[S]101Capabilityは記載します: [S]バージョン2[S]IHAVE[S] [C]MODE READER[S]502Transitサービス専用[サーバは接続を終えます。]
Example of use of the MODE READER command on a server that provides reading facilities:
読書施設を提供するサーバでMODE READERコマンドで役に立つ例:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] MODE READER
[S] 200 Reader mode, posting permitted
[C] IHAVE <i.am.an.article.you.have@example.com>
[S] 500 Permission denied
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] CAPABILITIES[S]101Capabilityは記載します: [S] バージョン2[S]読者[S]LIST ACTIVE NEWSGROUPS[S] [C]MODE READER[S]200読者モード、任命が[C] IHAVE <i.am.an.article.you.have@example.com を可能にした、gt;、[S]500Permissionは[C] GROUPミスクテスト[S]211に対して1234 3000234 3002322ミスクテストを否定しました。
Note that in both of these situations, the client SHOULD NOT use MODE READER.
これらの状況の両方では、クライアントSHOULD NOTがMODE READERを使用することに注意してください。
Feather Standards Track [Page 33] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[33ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Example of use of the MODE READER command on a mode-switching server:
モードを切り換えるサーバでMODE READERコマンドで役に立つ例:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] MODE-READER
[S] .
[C] MODE READER
[S] 200 Reader mode, posting permitted
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] NEWNEWS
[S] LIST ACTIVE NEWSGROUPS
[S] STARTTLS
[S] .
[C] CAPABILITIES[S]101Capabilityは記載します: [S]バージョン2[S]IHAVE[S]MODE-読者[S] [C] MODE READER[S]200読者モード、任命は[C]CAPABILITIES[S]101Capabilityリストを可能にしました: [S]バージョン2 [S] 読者[S]NEWNEWS[S]はアクティブなニュースグループ[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]201NNTP Service Ready、禁止された任命
5.4. QUIT
5.4. やめてください。
5.4.1. Usage
5.4.1. 用法
This command is mandatory.
このコマンドは義務的です。
Syntax
QUIT
構文はやめました。
Responses
205 Connection closing
応答205Connection閉鎖
5.4.2. Description
5.4.2. 記述
The client uses the QUIT command to terminate the session. The server MUST acknowledge the QUIT command and then close the connection to the client. This is the preferred method for a client to indicate that it has finished all of its transactions with the NNTP server.
クライアントはセッションを終えるQUITコマンドを使用します。 サーバは、QUITコマンドを承諾して、次に、接続をクライアントに終えなければなりません。 これはクライアントがNNTPサーバでトランザクションのすべてを終えたのを示す適した方法です。
Feather Standards Track [Page 34] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[34ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
If a client simply disconnects (or if the connection times out or some other fault occurs), the server MUST gracefully cease its attempts to service the client, disconnecting from its end if necessary.
クライアントが単に切断するなら(接続時間であるなら、アウトかある他の欠点が起こります)、サーバは優雅にクライアントにサービスを提供する試みをやめなければなりません、必要なら、終わりから切断して。
The server MUST NOT generate any response code to the QUIT command other than 205 or, if any arguments are provided, 501.
サーバは、どんな応答もコードであると205か501何か議論を提供するなら以外のQUITコマンドに生成してはいけません。
5.4.3. Examples
5.4.3. 例
[C] QUIT
[S] 205 closing connection
[Server closes connection.]
[C] 接続を終えるQUIT[S]205[サーバは接続を終えます。]
6. Article Posting and Retrieval
6. 記事任命と検索
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つのタイプのキーを使用することで、ニュース記事は、保存されて、索引をつけられます。 最初のタイプのキーは、記事のメッセージイドであり、グローバルにユニークです。 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と21億4748万3647の間なければなりません。 クライアントとサーバは、記事番号を指定する際に主なゼロを使用するかもしれませんが、16ケタ以上は使用してはいけません。 いくつかの状況で、値ゼロは、何らかの特別な状況を示しているために記事番号を置き換えます。
Note that it is likely that the article number limit of 2,147,483,647 will be increased by a future revision or extension to this specification. While servers MUST NOT send article numbers greater than this current limit, client and server developers are advised to
21億4748万3647の記事数の限界がこの仕様への今後の改正か拡大で増強されそうに注意してください。 クライアント、サーバはこの現在の限界より大きい記事数を送ってはいけません、そして、サーバ開発者はアドバイスされますが
Feather Standards Track [Page 35] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[35ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
use internal structures and datatypes capable of handling larger values in anticipation of such a change.
そのような変化を予測して、より大きい値を扱うことができる内部の構造とデータ型式を使用してください。
6.1. Group and Article Selection
6.1. グループと記事選択
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セッションの始めでは、これらの値の両方が特別な値の「病人」に設定されます。
6.1.1. GROUP
6.1.1. グループ
6.1.1.1. Usage
6.1.1.1. 用法
Indicating capability: READER
能力を示します: 読者
Syntax
GROUP group
構文GROUPグループ
Responses
211 number low high group Group successfully selected
411 No such newsgroup
応答211番号の低い高いグループGroupは首尾よくそのような411人のニュースグループを選択しませんでした。
Parameters
group Name of newsgroup
number Estimated number of articles in the group
low Reported low water mark
high Reported high water mark
パラメタはグループの低いReported干潮標高いReported最高水位線の記事のニュースグループ数のEstimated番号のNameを分類します。
6.1.1.2. Description
6.1.1.2. 記述
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.
うまくいっている選択応答は、選択(これらの数は「報告された干潮標」と「報告された最高水位線」と呼ばれる)の瞬間、現在利用可能なグループにおける、記事の数の見積りで1つの番目ものの記事番号を返して、グループで記事を持続するでしょう。
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
グループが空でないなら、見積りは、記事の有効な実数でなければならなく、違いよりさらに報告された安値と最高水位線の間の1以下であるに違いありません。 (いくつかの実装が実際に記事の数を数えるでしょう。
Feather Standards Track [Page 36] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[36ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
currently stored. Others will just subtract the low water mark from the high water mark and add one to get an estimate.)
現在、保存されています。 他のものは、最高水位線から干潮標をただ引き算して、見積りを得るために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つの状況の1つは起こるでしょう。 クライアントはすべての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になるでしょう、そして、およそ記事カウントはゼロになるでしょう。 サーバ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 記事数が報告された最高水位線より大きい状態で新品は加えられるかもしれません。 (最多数に従ってものであった記事を取り除いてあって、最高水位線がそれに従って、調整されたなら、次の新品で、ナンバーワンは報告された最高水位線よりすばらしくならないでしょう。)
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
グループが空であり、すべての3つの番号がゼロである時を除いて、少なくともそれのためのどんな前の応答でもそれがこのセッション、およびそれのニュースグループであったに違いないなら同じクライアントか異なったクライアント、応答における報告された干潮標で同じニュースグループのためのその後のGROUPコマンドを発行するときはいつも、SHOULDは今までどんなクライアントにも送られたそのニュースグループのためのどんな前の応答でもそのようにそうです。 後者状態SHOULDに会うために、一時的であってください。どんな失敗、も単に。 クライアントは下側の数がある記事のすべての覚えていられた情報を取り除くのに干潮標を利用するかもしれません、これらが決して再発しないとき。 最高水位線が干潮標よりそれほど1であるときに、これは状況を含んでいます。 これがすることができるように最高水位線に関してどんな同様の仮定もすることができません。
Feather Standards Track [Page 37] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[37ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
decrease if an article is removed and then increase again if it is reinstated or if new articles arrive.
記事が取り除かれるなら、減少してください、そして、復職するか、または新品が届くなら、次に、もう一度増加してください。
When a valid group is selected by means of this command, the currently selected newsgroup MUST be set to that group, and the current article number MUST be set to the first article in the group (this applies even if the group is already the currently selected newsgroup). If an empty newsgroup is selected, the current article number is made invalid. If an invalid group is specified, the currently selected newsgroup and current article number MUST NOT be changed.
有効なグループがこのコマンドによって選択されるとき、現在選択されたニュースグループをそのグループに設定しなければなりません、そして、グループにおける最初の記事に現在の記事番号を設定しなければなりません(これはグループが既に現在選択されたニュースグループであっても適用されます)。 空のニュースグループを選択するなら、現在の記事番号を無効にします。 無効のグループを指定するなら、現在選択されたニュースグループと現在の記事番号を変えてはいけません。
The GROUP or LISTGROUP command (see Section 6.1.2) MUST be used by a client, and a successful response received, before any other command is used that depends on the value of the currently selected newsgroup or current article number.
クライアントはGROUPかLISTGROUPコマンド(セクション6.1.2を見る)を使用しなければなりません、そして、うまくいっている応答は受信されました、そして、いかなる他のコマンドも使用されている前にそれは現在選択されたニュースグループか現在の記事番号の値に依存します。
If the group specified is not available on the server, a 411 response MUST be returned.
指定されたグループがサーバで利用可能でないなら、411応答を返さなければなりません。
6.1.1.3. Examples
6.1.1.3. 例
Example for a group known to the server:
サーバに知られているグループのための例:
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] GROUPミスクテスト[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]411example.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] GROUP example.currently.empty.newsgroup[S]211 0 4000 3999example.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]GROUP example.currently.empty.newsgroup[S]211 0 0 0example.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] GROUP example.currently.empty.newsgroup[S]211 0 4000 4321example.currently.empty.newsgroup
Feather Standards Track [Page 38] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[38ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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ミスクテスト[S]211 1234 234 567ミスクテスト[C]STAT444[S]223 444 <123456@example.net 、gt;、[C] GROUPミスクテスト[S]211 1234 234 567ミスクテスト[C]STAT[S]223 234 <different@example.net を検索する、gt;、検索
6.1.2. LISTGROUP
6.1.2. LISTGROUP
6.1.2.1. Usage
6.1.2.1. 用法
Indicating capability: READER
能力を示します: 読者
Syntax
LISTGROUP [group [range]]
構文LISTGROUP[グループ[範囲]]
Responses
211 number low high group Article numbers follow (multi-line)
411 No such newsgroup
412 No newsgroup selected [1]
応答211の数の下位の大きいグループArticle番号はどんなそのような411人のニュースグループ412いいえニュースグループも選択しなかった(マルチ系列)に続きます。[1]
Parameters
group Name of newsgroup
range Range of articles to report
number Estimated number of articles in the group
low Reported low water mark
high Reported high water mark
パラメタは、グループの低いReported干潮標高いReported最高水位線の記事の数のEstimated番号を報告するために記事のニュースグループ範囲RangeのNameを分類します。
[1] The 412 response can only occur if no group has been specified.
[1] グループが全く指定されていない場合にだけ、412応答は起こることができます。
6.1.2.2. Description
6.1.2.2. 記述
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
成功では、211応答コードに従って、マルチ系列データ・ブロックとして記事番号のリストを返します(初期の応答系列における議論はGROUPコマンドのように同じです)。 リストは、1系列あたり1つの数を含んでいて、番号にあります。 それは正確に選択の瞬間にグループで存在するそれらの記事をリストアップします(したがって、空のグループは空のリストを作り出します)。 任意の範囲議論が指定されるなら記事だけ、中
Feather Standards Track [Page 39] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[39ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
range are included in the list (therefore, the list MAY be empty even if the group is not).
範囲はリストに含まれています(したがって、グループが空でなくても、リストは空であるかもしれません)。
The range argument may be any of the following:
範囲議論は以下のいずれであるかもしれませんも:
o An article number.
o 記事番号。
o An article number followed by a dash to indicate all following.
o ダッシュで記事番号は、続いて、すべてを示すために従いました。
o An article number followed by a dash followed by another article
number.
o 別の記事番号があとに続いたダッシュで記事番号は従いました。
In the last case, if the second number is less than the first number, then the range contains no articles. Omitting the range is equivalent to the range 1- being specified.
最後の場合では、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.
グループ議論が任意であるのを除いて、範囲議論を指定できて、マルチ系列データ・ブロックが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.
範囲議論がこの仕様に基づき新機能であり、CAPABILITIES(したがって、この仕様に従わない)をサポートしないサーバがそれをサポートしそうにないことに注意してください。
6.1.2.3. Examples
6.1.2.3. 例
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ミスクテスト[S]211 2000 3000234 3002322ミスクテストリストは[S]3000234[S]3000237[S]3000238[S]3000239[S]3002322[S]に続きます。
Feather Standards Track [Page 40] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[40ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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 0example.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]3000239[S]3002322[S]に続きます。
Example of LISTGROUP with a range:
範囲があるLISTGROUPに関する例:
[C] LISTGROUP misc.test 3000238-3000248
[S] 211 2000 3000234 3002322 misc.test list follows
[S] 3000238
[S] 3000239
[S] .
[C] LISTGROUPミスクテスト3000238-3000248[S]211 2000 3000234 3002322ミスクテストリストは[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ミスクテスト12345678[S]211 2000 3000234 3002322ミスクテストリストは[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ミスクテスト9999-111[S]211 2000 3000234 3002322ミスクテストリストは[S]に続きます。
Feather Standards Track [Page 41] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[41ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
6.1.3. LAST
6.1.3. 最終
6.1.3.1. Usage
6.1.3.1. 用法
Indicating capability: READER
能力を示します: 読者
Syntax
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
Articleがどんなニュースグループも選択しなかった412を見つけた応答223nメッセージイド420Current記事番号はこのグループでいいえ前の無効の422記事です。
Parameters
n Article number
message-id Article message-id
パラメタn Article数のメッセージイドArticleメッセージイド
6.1.3.2. Description
6.1.3.2. 記述
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.
現在選択されたニュースグループが有効であるなら、そのニュースグループで現在の記事番号を前の記事に設定しなければなりません(すなわち、現在の記事番号より少ない最も大きい既存の記事番号)。 うまくいくなら、新しい現在の記事番号とその記事のメッセージイドを示す応答を返さなければなりません。 このコマンドに対応して記事テキストを全く送りません。
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とネクストコマンドの結果は特定のNNTPセッションの寿命の上で一貫していないかもしれません。
If the current article number is already the first article of the newsgroup, a 422 response MUST be returned. If the current article number is invalid, a 420 response MUST be returned. If the currently selected newsgroup is invalid, a 412 response MUST be returned. In all three cases, the currently selected newsgroup and current article number MUST NOT be altered.
現在の記事番号が既にニュースグループの最初の記事であるなら、422応答を返さなければなりません。 現在の記事番号が無効であるなら、420応答を返さなければなりません。 現在選択されたニュースグループが無効であるなら、412応答を返さなければなりません。 全部で、3つのケース、現在選択されたニュースグループ、および現在の記事番号を変更してはいけません。
Feather Standards Track [Page 42] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[42ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
6.1.3.3. Examples
6.1.3.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 、gt;、[C]LAST[S]223 3000234 <45223423@example.com を検索する、gt;、検索
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ミスクテスト[S]211 1234 3000234 3002322ミスクテスト[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 0example.empty.newsgroup[C]LAST[S]420
Feather Standards Track [Page 43] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[43ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
6.1.4. NEXT
6.1.4. 次へ
6.1.4.1. Usage
6.1.4.1. 用法
Indicating capability: 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
Articleがどんなニュースグループも選択しなかった412を見つけた応答223nメッセージイド420Current記事番号はこれの次の記事が分類する無効の421ノーです。
Parameters
n Article number
message-id Article message-id
パラメタn Article数のメッセージイドArticleメッセージイド
6.1.4.2. Description
6.1.4.2. 記述
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.
現在選択されたニュースグループが有効であるなら、そのニュースグループで現在の記事番号を次の記事に設定しなければなりません(すなわち、現在の記事番号より大きい最も下位の既存の記事数)。 うまくいくなら、新しい現在の記事番号とその記事のメッセージイドを示す応答を返さなければなりません。 このコマンドに対応して記事テキストを全く送りません。
If the current article number is already the last article of the newsgroup, a 421 response MUST be returned. In all other aspects (apart, of course, from the lack of 422 response), this command is identical to the LAST command (Section 6.1.3).
現在の記事番号が既にニュースグループに関する最後の記事であるなら、421応答を返さなければなりません。 他のすべての局面、(離れて、そして、もちろん、422応答の不足、)、このコマンドはLASTコマンド(セクション6.1.3)と同じです。
6.1.4.3. Examples
6.1.4.3. 例
Example of a successful article retrieval using NEXT:
ネクストを使用するうまくいっている記事検索に関する例:
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] NEXT
[S] 223 3000237 <668929@example.org> retrieved
[C] GROUPミスクテスト[S]211 1234 3000234 3002322ミスクテスト[C]ネクスト[S]223 3000237 <668929@example.org 、gt;、検索
Feather Standards Track [Page 44] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[44ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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] どんなニュースグループも選択しなかったネクスト[S]412
Example of an attempt to retrieve an article using the NEXT command when the current article number is that of the last article in the group:
現在の記事番号がグループにおける最後の記事のものであるときに、ネクストコマンドを使用することで記事を検索する試みに関する例:
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] STAT 3002322
[S] 223 3002322 <411@example.net> retrieved
[C] NEXT
[S] 421 No next article to retrieve
[C] GROUPミスクテスト[S]211 1234 3000234 3002322ミスクテスト[C]STAT3002322[S]223 3002322 <411@example.net 、gt;、検索する[C]ネクスト[S]421いいえ次記事を検索します。
Example of an attempt to retrieve an article using the NEXT command when the currently selected newsgroup is empty:
現在選択されたニュースグループが空であるときに、ネクストコマンドを使用することで記事を検索する試みに関する例:
[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 0example.empty.newsgroup[C]ネクスト[S]420
6.2. Retrieval of Articles and Article Sections
6.2. 記事と記事部の検索
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.
これらのコマンドの1つまで応じるとき、サーバは、全体の記事か適切な部分を提示しなければならなくて、何らかの方法でそれを変更するか、または翻訳するのを試みてはいけません。
Feather Standards Track [Page 45] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[45ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
6.2.1. ARTICLE
6.2.1. 記事
6.2.1.1. Usage
6.2.1.1. 用法
Indicating capability: READER
能力を示します: 読者
Syntax
ARTICLE message-id
ARTICLE number
ARTICLE
構文ARTICLEメッセージイドARTICLE番号ARTICLE
Responses
応答
First form (message-id specified)
220 0|n message-id Article follows (multi-line)
430 No article with that message-id
まず最初に、(メッセージイドは指定しました)220 0は形成されます。|nメッセージイドArticleはそのメッセージイドで430いいえ記事に従います(マルチ系列の)。
Second form (article number specified)
220 n message-id Article follows (multi-line)
412 No newsgroup selected
423 No article with that number
2番目のフォーム(記事番号は指定した)220nメッセージイドArticleはその数で(マルチ系列の)412いいえニュースグループの選択された423いいえ記事に従います。
Third form (current article number used)
220 n message-id Article follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
3番目のフォーム(数が使用した現在の記事)220nメッセージイドArticleは数が無効であるという(マルチ系列の)412いいえニュースグループの選択された420Current記事に従います。
Parameters
number Requested article number
n Returned article number
message-id Article message-id
パラメタはRequested記事No.n Returned記事数のメッセージイドArticleメッセージイドに付番します。
6.2.1.2. Description
6.2.1.2. 記述
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.
最初のフォームでは、メッセージイドは指定されます、そして、サーバはそのメッセージイドで記事を提示します。 この場合、サーバは現在選択されたニュースグループか現在の記事番号を変更してはいけません。 これは、ともに読まれる別の記事以内と適切な系列を決定するという意味困難ので参照をつけられるかもしれない記事のプレゼンテーションと1つ以上のニュースグループにクロスポストされたかもしれない記事の会員資格を容易にするためのものです。
Feather Standards Track [Page 46] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[46ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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).
応答では、現在選択されたニュースグループがない場合、記事番号をゼロに取り替えなければなりません、そして、記事がそのグループで存在している、その場合、サーバはそのグループに記事の番号を使用するかもしれません。 (サーバは現在選択されたニュースグループには記事があるか、またはそうだとすれば、それがどんな記事番号を持っているかを決定するのに必要ではありません; クライアントはいつもゼロが指定される用意ができていなければなりません。) すぐにこれに続く2番目のARTICLEコマンドにおけるその数の使用が同じ記事を返さないなら、サーバは記事番号を提供してはいけません。 サーバが、こういう事情ですから記事番号を返すのを選んでも、それほど一貫してする必要はありません。 また、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番目のフォームでは、記事番号は指定されます。 現在選択されたニュースグループにその数がある記事があれば、サーバは現在の記事番号をその数に設定しなければなりません。
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.
記事を取り除いてあるなら以前に有効な記事番号が無効になるかもしれないことに注意してください。 記事が復職したなら、以前に無効の記事番号は有効になるかもしれませんが、この記事番号は少なくともそのグループのための報告された干潮標でなければなりません。
The server MUST NOT change the currently selected newsgroup as a result of this command. The server MUST NOT change the current article number except when an article number argument was provided and the article exists; in particular, it MUST NOT change it following an unsuccessful response.
サーバはこのコマンドの結果、現在選択されたニュースグループを変えてはいけません。 記事数の議論が提供された時を除いて、サーバは現在の記事番号を変えてはいけません、そして、記事は存在しています。 失敗の応答に続いて、特に、それはそれを変えてはいけません。
Since the message-id is unique for each article, it may be used by a client to skip duplicate displays of articles that have been posted more than once, or to more than one newsgroup.
各記事に、メッセージイドがユニークであるので、それはクライアントによって一度掲示された以上である記事のスキップ写しディスプレイ、または1つ以上のニュースグループまで使用されるかもしれません。
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.
議論がメッセージイドであり、何かそのような記事が存在していないなら、430応答を返さなければなりません。 議論が数であるか省略されて、現在選択されたニュースグループが無効であるなら、412応答を返さなければなりません。 議論が数であり、その記事が現在選択されたニュースグループで存在していないなら、423応答を返さなければなりません。 議論が省略されて、現在の記事番号が無効であるなら、420応答を返さなければなりません。
Feather Standards Track [Page 47] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[47ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
6.2.1.3. Examples
6.2.1.3. 例
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ミスクテスト[S]211 1234 3000234 3002322ミスクテスト[C]ARTICLE[S]220 3000234 <45223423@example.com 、gt;、[S]経路: pathost!デモ!サクランボを載せたバニラアイス!メールでない[S]From: 「デモユーザ、「 <nobody@example.net 、gt;、[S]ニュースグループ:、」 ミスクテスト[S]Subject: 私はただテスト記事[S]日付:です。 1998年10月6日の04:38:40 -0500[S]組織: 例のネットの、そして、不確実なテキサス[S]メッセージID: <45223423@example.com>、[S] [S] これはただテスト記事です。 [S]。
Example of a successful retrieval of an article by message-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 、gt;、[S]220 0 <45223423@example.com 、gt;、[S]経路: pathost!デモ!サクランボを載せたバニラアイス!メールでない[S]From: 「デモユーザ、「 <nobody@example.net 、gt;、[S]ニュースグループ:、」 ミスクテスト[S]Subject: 私はただテスト記事[S]日付:です。 1998年10月6日の04:38:40 -0500[S]組織: 例のネットの、そして、不確実なテキサス[S]メッセージID: <45223423@example.com>、[S] [S] これはただテスト記事です。 [S]。
Example of an unsuccessful retrieval of an article by message-id:
メッセージイドによる記事の失敗の検索に関する例:
[C] ARTICLE <i.am.not.there@example.com>
[S] 430 No Such Article Found
[C] ARTICLE <i.am.not.there@example.com 、gt;、どんなそのような430の記事も見つけなかった[S]
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ミスクテスト[S]211 1234 3000234 3002322news.groups[C]ARTICLE300256[S]423いいえ記事
Feather Standards Track [Page 48] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[48ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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] どんなニュースグループも選択しなかったARTICLE300256[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 0example.empty.newsgroup[C]ARTICLE[S]420
6.2.2. HEAD
6.2.2. ヘッド
6.2.2.1. Usage
6.2.2.1. 用法
This command is mandatory.
このコマンドは義務的です。
Syntax
HEAD message-id
HEAD number
HEAD
構文HEADメッセージイドHEAD番号HEAD
Responses
応答
First form (message-id specified)
221 0|n message-id Headers follow (multi-line)
430 No article with that message-id
まず最初に、(メッセージイドは指定しました)221 0は形成されます。|nメッセージイドHeadersがそのメッセージイドで(マルチ系列の)430いいえ記事に従います。
Second form (article number specified)
221 n message-id Headers follow (multi-line)
412 No newsgroup selected
423 No article with that number
2番目のフォーム(記事番号は指定した)221nメッセージイドHeadersはその数で(マルチ系列の)412いいえニュースグループの選択された423いいえ記事に従います。
Third form (current article number used)
221 n message-id Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
Headersが従う3番目のフォーム(数が使用した現在の記事)221nメッセージイドの(マルチ系列の)412いいえニュースグループの選択された420Current記事番号は無効です。
Parameters
number Requested article number
n Returned article number
message-id Article message-id
パラメタはRequested記事No.n Returned記事数のメッセージイドArticleメッセージイドに付番します。
Feather Standards Track [Page 49] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[49ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
6.2.2.2. Description
6.2.2.2. 記述
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).
記事が存在しているなら、応答コードが220の代わりに221であり、ヘッダーだけが紹介されるのを除いて(ヘッダーとボディーを切り離す空の系列を含んではいけません)、HEADコマンドは同様にARTICLEコマンドに振る舞います。
6.2.2.3. Examples
6.2.2.3. 例
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ミスクテスト[S]211 1234 3000234 3002322ミスクテスト[C]HEAD[S]221 3000234 <45223423@example.com 、gt;、[S]経路: pathost!デモ!サクランボを載せたバニラアイス!メールでない[S]From: 「デモユーザ、「 <nobody@example.net 、gt;、[S]ニュースグループ:、」 ミスクテスト[S]Subject: 私はただテスト記事[S]日付:です。 1998年10月6日の04:38:40 -0500[S]組織: 例のネットの、そして、不確実なテキサス[S]メッセージID: <45223423@example.com>[S]。
Example of a successful retrieval of the headers of an article by message-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 、gt;、[S]221 0 <45223423@example.com 、gt;、[S]経路: pathost!デモ!サクランボを載せたバニラアイス!メールでない[S]From: 「デモユーザ、「 <nobody@example.net 、gt;、[S]ニュースグループ:、」 ミスクテスト[S]Subject: 私はただテスト記事[S]日付:です。 1998年10月6日の04:38:40 -0500[S]組織: 例のネットの、そして、不確実なテキサス[S]メッセージID: <45223423@example.com>[S]。
Example of an unsuccessful retrieval of the headers of an article by message-id:
メッセージイドによる記事のヘッダーの失敗の検索に関する例:
[C] HEAD <i.am.not.there@example.com>
[S] 430 No Such Article Found
[C] HEAD <i.am.not.there@example.com 、gt;、どんなそのような430の記事も見つけなかった[S]
Feather Standards Track [Page 50] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[50ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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ミスクテスト[S]211 1234 3000234 3002322ミスクテスト[C]HEAD300256[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] どんなニュースグループも選択しなかったHEAD300256[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 0example.empty.newsgroup[C]HEAD[S]420
6.2.3. BODY
6.2.3. ボディー
6.2.3.1. Usage
6.2.3.1. 用法
Indicating capability: READER
能力を示します: 読者
Syntax
BODY message-id
BODY number
BODY
構文BODYメッセージイドBODY番号BODY
Responses
応答
First form (message-id specified)
222 0|n message-id Body follows (multi-line)
430 No article with that message-id
まず最初に、(メッセージイドは指定しました)222 0は形成されます。|nメッセージイドBodyはそのメッセージイドで430いいえ記事に従います(マルチ系列の)。
Second form (article number specified)
222 n message-id Body follows (multi-line)
412 No newsgroup selected
423 No article with that number
2番目のフォーム(記事番号は指定した)222nメッセージイドBodyはその数で(マルチ系列の)412いいえニュースグループの選択された423いいえ記事に従います。
Feather Standards Track [Page 51] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[51ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Third form (current article number used)
222 n message-id Body follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
3番目のフォーム(数が使用した現在の記事)222nメッセージイドBodyは数が無効であるという(マルチ系列の)412いいえニュースグループの選択された420Current記事に従います。
Parameters
number Requested article number
n Returned article number
message-id Article message-id
パラメタはRequested記事No.n Returned記事数のメッセージイドArticleメッセージイドに付番します。
6.2.3.2. Description
6.2.3.2. 記述
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).
記事が存在しているなら、応答コードが220の代わりに222であり、ボディーだけが提示されるのを除いて(ヘッダーとボディーを切り離す空の系列を含んではいけません)、BODYコマンドは同様にARTICLEコマンドに振る舞います。
6.2.3.3. Examples
6.2.3.3. 例
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ミスクテスト[S]211 1234 3000234 3002322ミスクテスト[C]BODY[S]222 3000234 <45223423@example.com 、gt;、[S] これはただテスト記事です。 [S]。
Example of a successful retrieval of the body of an article by message-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 、gt;、[S]222 0 <45223423@example.com 、gt;、[S] これはただテスト記事です。 [S]。
Example of an unsuccessful retrieval of the body of an article by message-id:
メッセージイドによる記事のボディーの失敗の検索に関する例:
[C] BODY <i.am.not.there@example.com>
[S] 430 No Such Article Found
[C] BODY <i.am.not.there@example.com 、gt;、どんなそのような430の記事も見つけなかった[S]
Feather Standards Track [Page 52] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[52ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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]BODY300256[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] どんなニュースグループも選択しなかったBODY300256[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 0example.empty.newsgroup[C]BODY[S]420
6.2.4. STAT
6.2.4. スタット
6.2.4.1. Usage
6.2.4.1. 用法
This command is mandatory.
このコマンドは義務的です。
Syntax
STAT message-id
STAT number
STAT
構文STATメッセージイドSTAT番号STAT
Responses
応答
First form (message-id specified)
223 0|n message-id Article exists
430 No article with that message-id
まず最初に、(メッセージイドは指定しました)223 0は形成されます。|nメッセージイドArticleが存在している、そのメッセージイドがある430いいえ記事
Second form (article number specified)
223 n message-id Article exists
412 No newsgroup selected
423 No article with that number
2番目のフォーム(記事番号は指定した)223nメッセージイドArticleが存在している、412いいえニュースグループはその数がある423いいえ記事を選択しました。
Feather Standards Track [Page 53] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[53ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Third form (current article number used)
223 n message-id Article exists
412 No newsgroup selected
420 Current article number is invalid
3番目のフォーム(数が使用した現在の記事)223nメッセージイドArticleが存在している、412いいえニュースグループは数が無効であるという420Current記事を選択しました。
Parameters
number Requested article number
n Returned article number
message-id Article message-id
パラメタはRequested記事No.n Returned記事数のメッセージイドArticleメッセージイドに付番します。
6.2.4.2. Description
6.2.4.2. 記述
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.
記事が存在しているなら、それがクライアントに提示されないで、応答コードが220の代わりに223であるのを除いて、STATコマンドは同様に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番目のフォームのものであることを許容します、任意の量のテキストを処理する必要はなくて。
6.2.4.3. Examples
6.2.4.3. 例
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 、gt。
Example of STAT on an existing article by message-id:
メッセージイドによる既存の記事のSTATに関する例:
[C] STAT <45223423@example.com>
[S] 223 0 <45223423@example.com>
[C] STAT <45223423@example.com 、gt;、[S]223 0 <45223423@example.com 、gt。
Example of STAT on an article not on the server by message-id:
メッセージイドによるサーバでない記事のSTATに関する例:
[C] STAT <i.am.not.there@example.com>
[S] 430 No Such Article Found
[C] STAT <i.am.not.there@example.com 、gt;、どんなそのような430の記事も見つけなかった[S]
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]STAT300256[S]423いいえ記事
Feather Standards Track [Page 54] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[54ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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] どんなニュースグループも選択しなかったSTAT300256[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 0example.empty.newsgroup[C]STAT[S]420
Example of STAT by message-id on a server that sometimes reports the actual article number:
時々現品番号を報告するサーバに関するメッセージイドによるSTATに関する例:
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] STAT
[S] 223 3000234 <45223423@example.com>
[C] STAT <45223423@example.com>
[S] 223 0 <45223423@example.com>
[C] STAT <45223423@example.com>
[S] 223 3000234 <45223423@example.com>
[C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup
[C] STAT <45223423@example.com>
[S] 223 0 <45223423@example.com>
[C] GROUP alt.crossposts
[S] 211 9999 111111 222222 alt.crossposts
[C] STAT <45223423@example.com>
[S] 223 123456 <45223423@example.com>
[C] STAT
[S] 223 111111 <23894720@example.com>
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] STAT [S] 223 3000234 <45223423@example.com> [C] STAT <45223423@example.com> [S] 223 0 <45223423@example.com> [C] STAT <45223423@example.com> [S] 223 3000234 <45223423@example.com> [C] 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コマンドはグループにおける、記事のアイデンティティを確立します。 2番目としかし、サーバがそうする3番目のショー、必要性、メッセージイドが指定されるときの記事番号をお願いします。 4番目のSTATコマンドは、現在選択されたニュースグループに記事がないならゼロを指定しなければならないのを示します。 5番目は、提供するなら数が現在選択されたニュースグループとのその関係であるに違いないことを示します。 最後の人は、記事番号を返しても現在の記事番号がメッセージイドによるSTATの使用でまだ変えられていないのを示します。
Feather Standards Track [Page 55] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[55ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
6.3. Article Posting
6.3. 記事任命
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.
記事任命は2つの方法の1つで完了しています: ニュースを閲読するクライアントからのポストを使用する個々の記事任命、および他のニュースサーバからのIHAVEを使用する記事転送。
6.3.1. POST
6.3.1. ポスト
6.3.1.1. Usage
6.3.1.1. 用法
Indicating capability: POST
能力を示します: ポスト
This command MUST NOT be pipelined.
このコマンドをpipelinedしてはいけません。
Syntax
POST
構文ポスト
Responses
応答
Initial responses
340 Send article to be posted
440 Posting not permitted
掲示された440Postingである初期の応答340Send記事は可能にしませんでした。
Subsequent responses
240 Article received OK
441 Posting failed
その後の応答240のArticleの受信されたOK441Postingは失敗しました。
6.3.1.2. Description
6.3.1.2. 記述
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を見てください)。 その結果、ただ一つのドット、(「」、)、aでは、系列はテキストの端を示して、原本のドットから始まる系列はトランスミッションの間、そのドットを倍にします。
Following the presentation of the termination sequence by the client, the server MUST return a response indicating success or failure of the article transfer. Note that response codes 340 and 440 are used in direct response to the POST command while 240 and 441 are returned after the article is sent.
クライアントによる終止配列のプレゼンテーションに続いて、サーバは記事転送の成否を示す応答を返さなければなりません。 記事を送った後に240と441を返しますが、直接的な反応に応答コード340と440をポストコマンドに使用することに注意してください。
Feather Standards Track [Page 56] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[56ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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).
サーバで利用可能な状態で予期しないサーバ誤り、記事がされる掲示を禁じる、そして/または、他のサーバに移して、適宜、ことによると続いて、処理を促進するSHOULDが示す240の応答。 言い換えれば受け入れるより441応答でむしろ拒絶されて、次に、静かに捨てられて、サーバSHOULDによって欲しがられていなかった記事。 しかしながら、クライアントSHOULD NOTは、サーバから肯定的な応答を受けない場合記事が首尾よく移されたと仮定します、そして、SHOULD NOTはそれを明らかにチェックしないで(例えば、STATコマンドを使用します)他のクライアントにとって利用可能にしていると仮定します。
If the session is interrupted before the response is received, it is possible that an affirmative response was sent but has been lost. Therefore, in any subsequent session, the client SHOULD either check whether the article was successfully posted before resending or ensure that the server will allocate the same message-id to the new attempt (see Appendix A.2). The latter approach is preferred since the article might not have been made available for reading yet (for example, it may have to go through a moderation process).
応答が受け取られている前にセッションが中断されるなら、肯定的な応答を送りましたが、失ったのは可能です。 したがって、どんなその後のセッションのときにも、クライアントSHOULDは、記事が再送の前に首尾よく掲示されたかどうかチェックするか、またはサーバが同じメッセージイドを新しい試みに割り当てるのを確実にします(Appendix A.2を見てください)。 後者のアプローチは、記事をまだ読書しているのに利用可能にしていないかもしれなくて(例えば、それは中道主義者プロセスを通らなければならないかもしれません)、好まれます。
6.3.1.3. Examples
6.3.1.3. 例
Example of a successful posting:
うまくいっている任命に関する例:
[C] POST
[S] 340 Input article; end with <CR-LF>.<CR-LF>
[C] From: "Demo User" <nobody@example.net>
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Organization: An Example Net
[C]
[C] This is just a test article.
[C] .
[S] 240 Article received OK
[C]ポスト[S]340Input記事。 <CR-LF><CR-LF>[C]From:と共に終わってください。 「デモユーザ、「 <nobody@example.net 、gt;、[C]ニュースグループ:、」 ミスクテスト[C]Subject: 私はただテスト記事[C]組織です: Exampleネット、[C] [C] これはただテスト記事です。 [C] [S]240記事はOKを受けました。
Example of an unsuccessful posting:
失敗の任命に関する例:
[C] POST
[S] 340 Input article; end with <CR-LF>.<CR-LF>
[C] From: "Demo User" <nobody@example.net>
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Organization: An Example Net
[C]
[C] This is just a test article.
[C] .
[S] 441 Posting failed
[C]ポスト[S]340Input記事。 <CR-LF><CR-LF>[C]From:と共に終わってください。 「デモユーザ、「 <nobody@example.net 、gt;、[C]ニュースグループ:、」 ミスクテスト[C]Subject: 私はただテスト記事[C]組織です: Exampleネット、[C] [C] これはただテスト記事です。 [C] [S]441任命は失敗しました。
Feather Standards Track [Page 57] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[57ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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
[セットアップが終了した接続に頭文字をつけてください。] Postingが可能にしなかった禁止された[C]ポスト[S]440を掲示する[S]201NNTP Service Ready
6.3.2. IHAVE
6.3.2. IHAVE
6.3.2.1. Usage
6.3.2.1. 用法
Indicating capability: IHAVE
能力を示します: IHAVE
This command MUST NOT be pipelined.
このコマンドをpipelinedしてはいけません。
Syntax
IHAVE message-id
構文IHAVEメッセージイド
Responses
応答
Initial responses
335 Send article to be transferred
435 Article not wanted
436 Transfer not possible; try again later
436のTransferが立てないのが欲しくなかったわたっている435Articleになるように応答335Send記事に頭文字をつけてください。 後でもう一度試みてください。
Subsequent responses
235 Article transferred OK
436 Transfer failed; try again later
437 Transfer rejected; do not retry
その後の応答235のArticleのわたっているOK436Transferは失敗しました。 もう一度Transferが拒絶した後の437を試みてください。 再試行しないでください。
Parameters
message-id Article message-id
パラメタメッセージイドArticleメッセージイド
6.3.2.2. Description
6.3.2.2. 記述
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コマンドは、クライアントには指定されたメッセージイドがある記事があることをサーバに知らせます。 サーバがその記事のコピーを望んでいるなら、335応答を返さなければなりません、全体の記事を送るようクライアントに命令して。 サーバが記事を必要としないなら(例えば、サーバにそれのコピーが既にあるなら)、435応答を返さなければなりません、記事が欲しくないのを示して。 最終的に436応答を記事がすぐに、欲しくはありませんが、クライアントが後でできれば再試行するなら(例えば、同じ記事をサーバに送ることの途中に別のクライアントがいるなら)返さなければなりません。
Feather Standards Track [Page 58] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[58ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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を見てください)。 その結果、ただ一つのドット、(「」、)、aでは、系列はテキストの端を示して、原本のドットから始まる系列はトランスミッションの間、そのドットを倍にします。 記事が首尾よく移されたのを示して、サーバは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.
この機能は既に掲示された記事をホストの間に移すことにおける使用のために意図するという点においてポストコマンドと異なっています。 それ、SHOULD NOTをクライアントが個人的なニュースを閲読するプログラムであるときに、このコマンドの使用が、記事が別のサイトに既に掲示されたのを示すので、使用して、別のホストから単に進めています。 しかしながら、これにもかかわらず、サーバは、記事のさらなる調査の後にそうするのが不適当であると考えるなら、記事を掲示もしませんし、転送もしないのを選ぶかもしれません。 記事のそのようなその後の拒絶の理由が不適当なニュースグループなどの問題を含むかもしれませんか、または配(ディスク宇宙制限、記事の長さ)はヘッダー、および同様のものを誤り伝えました。 通常、これらは必ずNNTPサーバ自体によって励行されるのではなく、サーバー・ホストのニュースソフトウェアによって励行される制限です。
The client SHOULD NOT assume that the article has been successfully transferred unless it receives an affirmative response from the server. A lack of response (such as a dropped network connection or a network timeout) SHOULD be treated the same as a 436 response.
クライアントSHOULD NOTは. サーバA無反応(下げられたネットワーク接続かネットワークタイムアウトなどの)SHOULDから同じように436応答として扱われた状態で肯定的な応答を受けない場合記事が首尾よく移されたと仮定します。
Because some news server software may not immediately be able to determine whether an article is suitable for posting or forwarding, an NNTP server MAY acknowledge the successful transfer of the article (with a 235 response) but later silently discard it.
何らかのニュースサーバソフトウェアが、すぐに記事が任命か推進に適しているかどうか決定できないかもしれないので、NNTPサーバは、記事(235応答がある)のうまくいっている転送を承諾しますが、後で静かにそれを捨てるかもしれません。
Feather Standards Track [Page 59] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[59ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
6.3.2.3. Examples
6.3.2.3. 例
Example of successfully sending an article to another site:
首尾よく別のサイトに記事を送る例:
[C] IHAVE <i.am.an.article.you.will.want@example.com>
[S] 335 Send it; end with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: "Demo User" <nobody@example.com>
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: An Example Com, San Jose, CA
[C] Message-ID: <i.am.an.article.you.will.want@example.com>
[C]
[C] This is just a test article.
[C] .
[S] 235 Article transferred OK
[C] IHAVE <i.am.an.article.you.will.want@example.com 、gt;、[S]335Send、それ。 <CR-LF><CR-LF>[C]経路で、終わってください: pathost!デモ!、どこか、メールでない[C]From: 「デモユーザ、「 <nobody@example.com 、gt;、[C]ニュースグループ:、」 ミスクテスト[C]Subject: 私はただテスト記事[C]日付:です。 1998年10月6日の04:38:40 -0500[C]組織: Com、Exampleサンノゼ、カリフォルニア[C]Message ID: <i.am.an.article.you.will.want@example.com>[C][C]、これはテスト記事です。 [C] [S]235記事はOKを移しました。
Example of sending an article to another site that rejects it. Note that the message-id in the IHAVE command is not the same as the one in the article headers; while this is bad practice and SHOULD NOT be done, it is not forbidden.
それを拒絶する別のサイトに記事を送る例。 IHAVEコマンドにおけるメッセージイドが記事ヘッダーのものと同じでないことに注意してください。 これが悪い習慣とSHOULD NOTである間、してください、そして、それを禁じません。
[C] IHAVE <i.am.an.article.you.will.want@example.com>
[S] 335 Send it; end with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: "Demo User" <nobody@example.com>
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: An Example Com, San Jose, CA
[C] Message-ID: <i.am.an.article.you.have@example.com>
[C]
[C] This is just a test article.
[C] .
[S] 437 Article rejected; don't send again
[C] IHAVE <i.am.an.article.you.will.want@example.com 、gt;、[S]335Send、それ。 <CR-LF><CR-LF>[C]経路で、終わってください: pathost!デモ!、どこか、メールでない[C]From: 「デモユーザ、「 <nobody@example.com 、gt;、[C]ニュースグループ:、」 ミスクテスト[C]Subject: 私はただテスト記事[C]日付:です。 1998年10月6日の04:38:40 -0500[C]組織: Com、Exampleサンノゼ、カリフォルニア[C]Message ID: <i.am.an.article.you.have@example.com>[C][C]、これはテスト記事です。 [C] 拒絶された[S]437記事。 再び発信しないでください。
Feather Standards Track [Page 60] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[60ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Example of sending an article to another site where the transfer fails:
転送が失敗する別のサイトに記事を送る例:
[C] IHAVE <i.am.an.article.you.will.want@example.com>
[S] 335 Send it; end with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: "Demo User" <nobody@example.com>
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: An Example Com, San Jose, CA
[C] Message-ID: <i.am.an.article.you.will.want@example.com>
[C]
[C] This is just a test article.
[C] .
[S] 436 Transfer failed
[C] IHAVE <i.am.an.article.you.will.want@example.com 、gt;、[S]335Send、それ。 <CR-LF><CR-LF>[C]経路で、終わってください: pathost!デモ!、どこか、メールでない[C]From: 「デモユーザ、「 <nobody@example.com 、gt;、[C]ニュースグループ:、」 ミスクテスト[C]Subject: 私はただテスト記事[C]日付:です。 1998年10月6日の04:38:40 -0500[C]組織: Com、Exampleサンノゼ、カリフォルニア[C]Message ID: <i.am.an.article.you.will.want@example.com>[C][C]、これはテスト記事です。 [C] [S]436転送は失敗しました。
Example of sending an article to a site that already has it:
既にそれを持っているサイトに記事を送る例:
[C] IHAVE <i.am.an.article.you.have@example.com>
[S] 435 Duplicate
[C] IHAVE <i.am.an.article.you.have@example.com 、gt;、[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 、gt;、後での[S]436Retry
7. Information Commands
7. 情報コマンド
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.
このセクションはいつでもセッションの始まりとその終了の間で使用されるかもしれない他のコマンドを記載します。 これらのコマンドを使用するのは少しの州の情報も変更しませんが、彼らの使用から発生する応答は役に立つ情報をクライアントに提供するかもしれません。
7.1. DATE
7.1. 日付
7.1.1. Usage
7.1.1. 用法
Indicating capability: READER
能力を示します: 読者
Syntax
DATE
構文日付
Responses
111 yyyymmddhhmmss Server date and time
yyyymmddhhmmss Serverが日付を入れる応答111と時間
Feather Standards Track [Page 61] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[61ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Parameters
yyyymmddhhmmss Current UTC date and time on server
サーバのパラメタyyyymmddhhmmss Current UTC日時
7.1.2. Description
7.1.2. 記述
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]を見つけるのを助けるために存在しています。 これは、SHOULD NOTが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を見てください)。 これはSHOULDの時間を計ります。単調であってください、調整SHOULDはそれを速く走らせることによって作られているか、または突然のジャンプをすることによってというよりむしろ「本当」の時間と比べて、遅くなります。 できるだけNTPかある他の方法によって正確なシステムクロックをSHOULDが保つNNTPサービスに提供するシステム。
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応答を返さなければなりません。 協定世界時に、この日時はあります。
7.1.3. Examples
7.1.3. 例
[C] DATE
[S] 111 19990623135624
[C]日付[S]111 19990623135624
7.2. HELP
7.2. ヘルプ
7.2.1. Usage
7.2.1. 用法
This command is mandatory.
このコマンドは義務的です。
Syntax
HELP
構文支援
Responses
100 Help text follows (multi-line)
応答100ヘルプテキストは従います。(マルチ線)です。
7.2.2. Description
7.2.2. 記述
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応答コードに従って、助けテキストはマルチ線データ・ブロックとして提示されるでしょう。
Feather Standards Track [Page 62] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[62ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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でなければならない)にもあるように保証しないで、CAPABILITIESコマンドとの交換がセクション5.2で説明したようにクライアントは使用してはいけません。
7.2.3. Examples
7.2.3. 例
[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] ヘルプ[S]100ヘルプテキストは従います。[S] これによる或るものがテキストを助けるということです。 このテストのためのどんな特定の[S]形式要件もありません、[S] 有効なコマンド[S]を記載して、それらがすることに関する簡潔な定義を与えるのが、通例ですが。 [S]。
7.3. NEWGROUPS
7.3. NEWGROUPS
7.3.1. Usage
7.3.1. 用法
Indicating capability: READER
能力を示します: 読者
Syntax
NEWGROUPS date time [GMT]
構文NEWGROUPS日付の時間[グリニッジ標準時]
Responses
231 List of new newsgroups follows (multi-line)
新しいニュースグループの応答231Listは続きます。(マルチ線)です。
Parameters
date Date in yymmdd or yyyymmdd format
time Time in hhmmss format
パラメタのyymmddの日付Dateかhhmmss形式におけるyyyymmdd形式時間Time
7.3.2. Description
7.3.2. 記述
This command returns a list of newsgroups created on the server since the specified date and time. The results are in the same format as the LIST ACTIVE command (see Section 7.6.3). However, they MAY include groups not available on the server (and so not returned by LIST ACTIVE) and MAY omit groups for which the creation date is not available.
このコマンドは指定された日時以来サーバに創設されたニュースグループのリストを返します。 LIST ACTIVEコマンドと同じ形式には結果があります(セクション7.6.3を見てください)。 しかしながら、彼らは、サーバで利用可能でなくて(そのようにLIST ACTIVEによって返されません)のグループを含んで、作成日付が空いていないグループを省略するかもしれません。
The date is specified as 6 or 8 digits in the format [xx]yymmdd, where xx is the first two digits of the year (19-99), yy is the last two digits of the year (00-99), mm is the month (01-12), and dd is the day of the month (01-31). Clients SHOULD specify all four digits of the year. If the first two digits of the year are not specified (this is supported only for backward compatibility), the year is to be taken from the current century if yy is smaller than or equal to the current year, and the previous century otherwise.
日付は6ケタか8ケタとして形式[xx]yymmddで指定されます、そして、yyは年(00-99)の下2ケタです、そして、mmは月(01-12)です、そして、ddは月(01-31)の日です。(そこでは、xxが年(19-99)の最初の2ケタです)。 クライアントSHOULDは1年のすべての4ケタを指定します。 そうでなければ、yyが本年度、より前世紀以下であり、1年の最初の2ケタを指定しないなら(これは後方の互換性のためだけに支持されます)、年は現在の世紀から取ることです。
Feather Standards Track [Page 63] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[63ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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.
時間が6ケタとしてhhが24時間の時計(00-23)の数時間である形式hhmmssで指定されて、mmが議事録(00-59)であり、ssが秒である、(00-60、飛躍秒の間、許容する、) 「グリニッジ標準時」の象徴は、日付と時間が協定世界時[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.
クライアントSHOULDは、可能であるときに、協定世界時(すなわち、「グリニッジ標準時」という議論を含んでいるのによる)を使用することですべての質問をします。
7.3.3. Examples
7.3.3. 例
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] 新しいニュースグループのNEWGROUPS19990624グリニッジ標準時000000[S]231リストは[S] alt.rfc-writers.recovery4 1y[S]tx.natives.recovery89 56y[S]に続きます。
Example where there are no new groups:
どんな新しいグループもない例:
[C] NEWGROUPS 19990624 000000 GMT
[S] 231 list of new newsgroups follows
[S] .
[C] 新しいニュースグループのNEWGROUPS19990624グリニッジ標準時000000[S]231リストは[S]に続きます。
7.4. NEWNEWS
7.4. NEWNEWS
7.4.1. Usage
7.4.1. 用法
Indicating capability: NEWNEWS
能力を示します: NEWNEWS
Syntax
NEWNEWS wildmat date time [GMT]
構文NEWNEWS wildmat日付の時間[グリニッジ標準時]
Responses
230 List of new articles follows (multi-line)
新品の応答230Listは続きます。(マルチ線)です。
Parameters
wildmat Newsgroups of interest
date Date in yymmdd or yyyymmdd format
time Time in hhmmss format
yymmddの関心日付Dateかhhmmss形式におけるyyyymmdd形式時間Timeのパラメタwildmatニュースグループ
Feather Standards Track [Page 64] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[64ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
7.4.2. Description
7.4.2. 記述
This command returns a list of message-ids of articles posted or received on the server, in the newsgroups whose names match the wildmat, since the specified date and time. One message-id is sent on each line; the order of the response has no specific significance and may vary from response to response in the same session. A message-id MAY appear more than once; if it does, it has the same meaning as if it appeared only once.
このコマンドはサーバに掲示されるか、または受け取られた記事のメッセージイドのリストを返します、名前がwildmatに合っているニュースグループで、指定された日時以来。 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.
協定世界時(すなわち、「グリニッジ標準時」という議論を使用するのによる)に可能であるときに、クライアントSHOULDはすべての質問をします。
7.4.3. Examples
7.4.3. 例
Example where there are new articles:
新品がある例:
[C] NEWNEWS news.*,sci.* 19990624 000000 GMT
[S] 230 list of new articles by message-id follows
[S] <i.am.a.new.article@example.com>
[S] <i.am.another.new.article@example.com>
[S] .
[C] NEWNEWSニュース*、sciメッセージイドによる新品の*19990624グリニッジ標準時000000[S]230リストが[S] <i.am.a.new.article@example.com に続く、gt;、[S]、lt;、 i.am.another.new.article@example.com 、gt;、[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[S]230リストは[S]に続きます。
7.5. Time
7.5. 時間
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は、以前に選ばれたタイムスタンプを使用することで命令します。
Feather Standards Track [Page 65] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[65ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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分調整したがっているかもしれません。
7.5.1. Examples
7.5.1. 例
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] グリニッジ標準時の[S]230が記載するDATE[S]111 20010203112233[C]NEWNEWS local.chat20001231 235959が[S] <article.1@local.service に続く、gt;、[S] <article.2@local.service 、gt;、[S] <article.3@local.service 、gt;、[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] グリニッジ標準時の[S]230が記載するDATE[S]111 20010204003344[C]NEWNEWS local.chat20010203 111933が[S] <article.3@local.service に続く、gt;、[S] <article.4@local.service 、gt;、[S] <article.5@local.service 、gt;、[S]。
Note how <article.3@local.service> arrived in the 3 minute gap and so is listed in both responses.
how <article.3@local.service に注意してください、gt;、3分のギャップに到着するので、両方の応答では、記載されています。
7.6. The LIST Commands
7.6. リストコマンド
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ニュースグループあたり1つの線があります、そして、情報が返されるグループを制限するためにwildmatを提供するかもしれません。
The set of available keywords (including those provided by extensions) is given in the capability list with capability label LIST.
能力ラベルLISTがあるケイパビリティ・リストで利用可能なキーワード(拡大で提供されたものを含んでいる)のセットを与えます。
Feather Standards Track [Page 66] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[66ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
7.6.1. LIST
7.6.1. リスト
7.6.1.1. Usage
7.6.1.1. 用法
Indicating capability: LIST
能力を示します: リスト
Syntax
LIST [keyword [wildmat|argument]]
構文リスト[キーワード[wildmat| 議論]]
Responses
215 Information follows (multi-line)
応答215情報は従います。(マルチ線)です。
Parameters
keyword Information requested [1]
argument Specific to keyword
wildmat Groups of interest
パラメタキーワード情報は興味があるキーワードwildmat Groupsに[1] 議論Specificを要求しました。
[1] If no keyword is provided, it defaults to ACTIVE.
[1] キーワードを全く提供しないなら、それはACTIVEをデフォルトとします。
7.6.1.2. Description
7.6.1.2. 記述
The LIST command allows the server to provide blocks of information to the client. This information may be global or may be related to newsgroups; in the latter case, the information may be returned either for all groups or only for those matching a wildmat. Each block of information is represented by a different keyword. The command returns the specific information identified by the keyword.
LISTコマンドで、サーバはブロックの情報をクライアントに提供できます。 この情報は、グローバルであるかもしれないか、またはニュースグループに関連するかもしれません。 後者の場合では、すべてのグループかwildmatに合っているもののためだけに情報を返すかもしれません。 それぞれのブロックの情報は異なったキーワードによって表されます。 コマンドはキーワードによって特定された特殊情報を返します。
If the information is available, it is returned as a multi-line data block following the 215 response code. The format of the information depends on the keyword. The information MAY be affected by the additional argument, but the format MUST NOT be.
情報が利用可能であるなら、215応答コードに従って、マルチ線データ・ブロックとしてそれを返します。 情報の形式はキーワードに依存します。 情報は追加議論で影響を受けるかもしれませんが、形式は影響を受けるはずがありません。
If the information is based on newsgroups and the optional wildmat argument is specified, the response is limited to only the groups (if any) whose names match the wildmat and for which the information is available.
情報がニュースグループに基づいていて、任意のwildmat議論が指定されるなら、応答は名前がwildmatに合って、情報が利用可能であるグループ(もしあれば)だけに制限されます。
Note that an empty list is a possible valid response; for a newsgroup-based keyword, it indicates that there are no groups meeting the above criteria.
空のリストが可能な有効回答であることに注意してください。 ニュースグループベースのキーワードに関しては、それは、上の評価基準を満たすグループが全くないのを示します。
If the keyword is not recognised, or if an argument is specified and the keyword does not expect one, a 501 response code MUST BE returned. If the keyword is recognised but the server does not maintain the information, a 503 response code MUST BE returned.
議論が指定されて、キーワードが1つを期待しないならキーワードが認識されないなら、501応答コードを返さなければなりません。 キーワードが認識されますが、サーバが情報を保守しないなら、503応答コードを返さなければなりません。
Feather Standards Track [Page 67] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[67ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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コマンドを発行したかどうかによって影響を受けてはいけません。 例えば、それでグループは利用可能になってはいけません。そうでなければ、それはいなかったでしょう。
7.6.1.3. Examples
7.6.1.3. 例
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] ミスクテスト3002322 3000234y[S]comp.risks442001 441099m[S]alt.rfc-writers.recovery4 1y[S]tx.natives.recovery89 56y[S]tx.natives.recovery.d11 9n[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] ミスクテスト3002322 3000234y[S]comp.risks442001 441099m[S]alt.rfc-writers.recovery4 1y[S]tx.natives.recovery89 56y[S]tx.natives.recovery.d11 9n[S]に続きます。
The output is identical to that of the previous example.
出力は前の例のものと同じです。
Example of LIST on a newsgroup-based keyword with and without wildmat:
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] ミスクテスト 930445408 <creatme@isc.org に続く、gt;、[S] alt.rfc-writers.recovery 930562309 <m@example.com 、gt;、[S] tx.natives.recovery 930678923 <sob@academ.com 、gt;、[S] [C]LIST ACTIVE.TIMES tx*[S]215情報が[S] tx.natives.recovery 930678923 <sob@academ.com に続く、gt;、[S]。
Feather Standards Track [Page 68] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[68ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Example of LIST returning an error where the keyword is recognized but the software does not maintain this information:
キーワードが認識されるところに誤りを返すLISTにもかかわらず、ソフトウェアに関する例はこの情報を保守しません:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA
[S] .
[C] LIST XTRA.DATA
[S] 503 Data item not stored
[C] CAPABILITIES[S]101Capabilityは記載します: [S]バージョン2[S]読者[S]LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA[S] LIST XTRA.DATA[S]503Dataの品目が格納しなかった[C]
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] CAPABILITIES[S]101Capabilityは記載します: [S]バージョン2[S]読者[S]のリストのアクティブなニュースグループACTIVE.TIMES XTRA.DATA[S][C] リストDISTRIB.PATS[S]501構文エラー
7.6.2. Standard LIST Keywords
7.6.2. 標準のリストキーワード
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 | +--------------+---------------+------------------------------------+
+--------------+---------------+------------------------------------+ | キーワード| 定義| 状態| +--------------+---------------+------------------------------------+ | アクティブ| セクション7.6 .3| 義務的である、読者能力です。| | | | 広告を出します。| | | | | | ACTIVE.TIMES| セクション7.6 .4| 任意| | | | | | DISTRIB.PATS| セクション7.6 .5| 任意| | | | | | ヘッダー| セクション8.6| HDRであるなら能力がそうであることが義務的です。| | | | 広告を出します。| | | | | | ニュースグループ| セクション7.6 .6| 義務的である、読者能力です。| | | | 広告を出します。| | | | | | OVERVIEW.FMT| セクション8.4| 義務的である、OVER能力です。| | | | 広告を出します。| +--------------+---------------+------------------------------------+
Feather Standards Track [Page 69] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[69ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Where one of these LIST keywords is supported by a server, it MUST have the meaning given in the relevant sub-section.
これらのLISTキーワードの1つがサーバによって支持されるところでは、それで、関連小区分で意味を与えなければなりません。
7.6.3. LIST ACTIVE
7.6.3. リストアクティブです。
This keyword MUST be supported by servers advertising the READER capability.
読者能力の広告を出すサーバでこのキーワードを支持しなければなりません。
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は有効なニュースグループと関連情報のリストを返します。 wildmatが全く指定されないなら、サーバはクライアントがGROUPコマンド(セクション6.1.1)で選択することを許可されているあらゆるグループを含まなければなりません。 このリストの各線は1つ以上の空間によって互いと切り離された4つの野原から成ります:
o The name of the newsgroup. o The reported high water mark for the group. o The reported low water mark for the group. o The current status of the group on this server.
o ニュースグループの名前. ○ グループのための報告された最高水位線、○ グループのための報告された干潮標. ○ このサーバに関するグループの現在の状態。
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:
通常、状態分野は以下の1つです:
"y" Posting is permitted.
「y」任命は受入れられます。
"n" Posting is not permitted.
「n」Postingは受入れられません。
"m" Postings will be forwarded to the newsgroup moderator.
「m」Postingsをニュースグループ議長に送るでしょう。
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はこれらの値を使用します。 状態への他の値は存在するかもしれません。 それらが返されるこれらの他の値と事情の定義は、拡大で指定されるかもしれないか、またはサーバに個人的であるかもしれません。クライアント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」をグループに掲示します。
Feather Standards Track [Page 70] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[70ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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] ミスクテスト3002322 3000234y[S]comp.risks442001 441099m[S]alt.rfc-writers.recovery4 1y[S]tx.natives.recovery89 56y[S]tx.natives.recovery.d11 9n[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] ミスクテスト0003002322 0003000234y[S]comp.risks0000442001 0000441099m[S]alt.rfc-writers.recovery0000000004 0000000001y[S]tx.natives.recovery0000000089 0000000056y[S]tx.natives.recovery.d0000000011 0000000009n[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:
情報は基づくニュースグループです、そして、wildmatは指定されるかもしれません、そして、その場合、応答は名前がwildmatに合っているグループ(もしあれば)だけに制限されます。 例えば:
[C] LIST ACTIVE *.recovery
[S] 215 list of newsgroups follows
[S] alt.rfc-writers.recovery 4 1 y
[S] tx.natives.recovery 89 56 y
[S] .
[C] ニュースグループのLIST ACTIVE*.recovery[S]215リストは[S] alt.rfc-writers.recovery4 1y[S]tx.natives.recovery89 56y[S]に続きます。
7.6.4. LIST ACTIVE.TIMES
7.6.4. リストACTIVE.TIMES
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番目はニュースグループを創設した実体について説明することを意図するプレーンテキストです。 しばしばそれはRFC2822[RFC2822]で定義されるようにメールボックスです。 例えば:
Feather Standards Track [Page 71] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[71ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
[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] ミスクテスト 930445408 <creatme@isc.org に続く、gt;、[S] alt.rfc-writers.recovery 930562309 <m@example.com 、gt;、[S] tx.natives.recovery 930678923 <sob@academ.com 、gt;、[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.
リストは、情報が入手できないニュースグループを省略して、サーバで利用可能でないグループを含むかもしれません。 特に、それは最も古いエントリーの日時以前創設されたすべてのグループを省略するかもしれません。 クライアントは、リストが完全であるか、またはLIST ACTIVEコマンド(セクション7.6.3)で返されたリストを合わせると仮定してはいけません。 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.
情報は基づくニュースグループです、そして、wildmatは指定されるかもしれません、そして、その場合、応答は名前がwildmatに合っているグループ(もしあれば)だけに制限されます。
7.6.5. LIST DISTRIB.PATS
7.6.5. リストDISTRIB.PATS
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番目の分野はwildmat(簡単なニュースグループ名であるかもしれない)です、そして、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に続きます: 地方です。*: 地方の[S]5: *: 世界[S]20: local.here*: thissite[S]。
The client MAY use this information to construct an appropriate Distribution header given the name of a newsgroup. To do so, it should determine the lines whose second field matches the newsgroup name, select from among them the line with the highest weight (with 0 being the lowest), and use the value of the third field to construct the Distribution header.
ニュースグループの名前を考えて、クライアントは、適切なDistributionヘッダーを組み立てるのにこの情報を使用するかもしれません。 それは、そうするのに、2番目の分野がニュースグループ名に合っている線を決定して、それらの中で最も高い重さ(0が最も低い)で線から選び抜いて、Distributionヘッダーを組み立てる3番目の分野の値を使用するべきです。
Feather Standards Track [Page 72] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[72ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
The information is not newsgroup based, and an argument MUST NOT be specified.
情報は基づくニュースグループではありません、そして、議論は指定されてはいけません。
7.6.6. LIST NEWSGROUPS
7.6.6. リストニュースグループ
This keyword MUST be supported by servers advertising the READER capability.
読者能力の広告を出すサーバでこのキーワードを支持しなければなりません。
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キャラクタによって互いと切り離された2つの野原から成ります(恒例は独身のTABです)。 最初の分野はニュースグループの名前です、そして、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] [S] alt.rfc-writers.recovery RFC Writers Recovery[S]tx.natives.recoveryテキサスNatives Recovery[S]をテストするミスクテストUsenet司令官に続きます。
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によって返されたリストを合わせると仮定してはいけません。
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.
記述SHOULDはUTF-8のそうです。 しかしながら、サーバは外部電源から情報をしばしば得ます。 これらのソースは異なったencodings(範囲である他の方法で128〜255に八重奏を使用するもの)を使用したかもしれません、そして、その場合、サーバは変わりがない状態でそれを伝えるかもしれません。 したがって、クライアントはそのような記述を受ける用意ができていなければなりません。
The information is newsgroup based, and a wildmat MAY be specified, in which case the response is limited to only the groups (if any) whose names match the wildmat.
情報は基づくニュースグループです、そして、wildmatは指定されるかもしれません、そして、その場合、応答は名前がwildmatに合っているグループ(もしあれば)だけに制限されます。
8. Article Field Access Commands
8. 記事分野アクセス命令
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 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.
Feather Standards Track [Page 73] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 73] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
This section is based on the Overview/NOV database [ROBE1995] developed by Geoff Collyer.
This section is based on the Overview/NOV database [ROBE1995] developed by Geoff Collyer.
8.1. Article Metadata
8.1. Article Metadata
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.
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.
When generating a metadata item, the server MUST compute it for itself and MUST NOT trust any related value provided in the article. (In particular, a Lines or Bytes header in the article MUST NOT be assumed to specify the correct number of lines or bytes in the article.) If the server has access to several non-identical copies of an article, the value returned MUST be correct for any copy of that article retrieved during the same session.
This specification defines two metadata items: ":bytes" and ":lines". Other metadata items may be defined by extensions. The names of metadata items defined by registered extensions MUST NOT begin with ":x-". To avoid the risk of a clash with a future registered extension, the names of metadata items defined by private extensions SHOULD begin with ":x-".
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-".
8.1.1. The :bytes Metadata Item
8.1.1. The :bytes Metadata Item
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).
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).
Note to client implementers: some existing servers return a value different from that above. The commonest reasons for this are as follows:
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 Counting a CRLF pair as one octet.
o Including the "." character used for dot-stuffing in the number.
o Including the "." character used for dot-stuffing in the number.
o Including the terminating "." CRLF in the number.
o Including the terminating "." CRLF in the number.
o Using one copy of an article for counting the octets but then
returning another one that differs in some (permitted) manner.
o Using one copy of an article for counting the octets but then returning another one that differs in some (permitted) manner.
Implementations should be prepared for such variation and MUST NOT rely on the value being accurate.
Implementations should be prepared for such variation and MUST NOT rely on the value being accurate.
Feather Standards Track [Page 74] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 74] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
8.1.2. The :lines Metadata Item
8.1.2. The :lines Metadata Item
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).
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).
8.2. Database Consistency
8.2. Database Consistency
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 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).
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).
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.
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.
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.
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.
Feather Standards Track [Page 75] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 75] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
8.3. OVER
8.3. OVER
8.3.1. Usage
8.3.1. Usage
Indicating capability: OVER
Indicating capability: OVER
Syntax
OVER message-id
OVER range
OVER
Syntax OVER message-id OVER range OVER
Responses
Responses
First form (message-id specified)
224 Overview information follows (multi-line)
430 No article with that message-id
First form (message-id specified) 224 Overview information follows (multi-line) 430 No article with that message-id
Second form (range specified)
224 Overview information follows (multi-line)
412 No newsgroup selected
423 No articles in that range
Second form (range specified) 224 Overview information follows (multi-line) 412 No newsgroup selected 423 No articles in that range
Third form (current article number used)
224 Overview information follows (multi-line)
412 No newsgroup selected
420 Current article number is invalid
Third form (current article number used) 224 Overview information follows (multi-line) 412 No newsgroup selected 420 Current article number is invalid
Parameters
range Number(s) of articles
message-id Message-id of article
Parameters range Number(s) of articles message-id Message-id of article
8.3.2. Description
8.3.2. Description
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.
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.
The message-id argument indicates a specific article. The range argument may be any of the following:
The message-id argument indicates a specific article. The range argument may be any of the following:
o An article number.
o An article number.
o An article number followed by a dash to indicate all following.
o An article number followed by a dash to indicate all following.
o An article number followed by a dash followed by another article
number.
o An article number followed by a dash followed by another article number.
If neither is specified, the current article number is used.
If neither is specified, the current article number is used.
Feather Standards Track [Page 76] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 76] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
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.
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.
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.
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.
The first 8 fields MUST be the following, in order:
The first 8 fields MUST be the following, in order:
"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" 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
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.
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.
Any subsequent fields are the contents of the other headers and metadata held in the database.
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.
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.
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.
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.
Feather Standards Track [Page 77] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 77] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
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.
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.
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.
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.
The server SHOULD NOT produce output for articles that no longer exist.
The server SHOULD NOT produce output for articles that no longer exist.
If the argument is a message-id and no such article exists, a 430 response MUST be returned. If the argument is a range or is omitted and the currently selected newsgroup is invalid, a 412 response MUST be returned. If the argument is a range and no articles in that number range exist in the currently selected newsgroup, including the case where the second number is less than the first one, a 423 response MUST be returned. If the argument is omitted and the current article number is invalid, a 420 response MUST be returned.
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.
8.3.3. Examples
8.3.3. Examples
In the first four examples, TAB has been replaced by vertical bar and some lines have been folded for readability.
In the first four examples, TAB has been replaced by vertical bar and some lines have been folded for readability.
Example of a successful retrieval of overview information for an article (explicitly not using an article number):
Example of a successful retrieval of overview information for an article (explicitly not using an article number):
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] OVER
[S] 224 Overview information follows
[S] 3000234|I am just a test article|"Demo User"
<nobody@example.com>|6 Oct 1998 04:38:40 -0500|
<45223423@example.com>|<45454@example.net>|1234|
17|Xref: news.example.com misc.test:3000363
[S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [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] .
Feather Standards Track [Page 78] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 78] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Example of a successful retrieval of overview information for an article by message-id:
Example of a successful retrieval of overview information for an article by message-id:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] OVER MSGID
[S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
[S] .
[C] OVER <45223423@example.com>
[S] 224 Overview information follows
[S] 0|I am just a test article|"Demo User"
<nobody@example.com>|6 Oct 1998 04:38:40 -0500|
<45223423@example.com>|<45454@example.net>|1234|
17|Xref: news.example.com misc.test:3000363
[S] .
[C] CAPABILITIES [S] 101 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] .
Note that the article number has been replaced by "0".
Note that the article number has been replaced by "0".
Example of the same commands on a system that does not implement retrieval by message-id:
Example of the same commands on a system that does not implement retrieval by message-id:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] OVER
[S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
[S] .
[C] OVER <45223423@example.com>
[S] 503 Overview by message-id unsupported
[C] CAPABILITIES [S] 101 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
Feather Standards Track [Page 79] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 79] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Example of a successful retrieval of overview information for a range of articles:
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 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] .
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.
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.
Example of an unsuccessful retrieval of overview information on an article by number:
Example of an unsuccessful retrieval of overview information on an article by number:
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] OVER 300256
[S] 423 No such article in this group
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] OVER 300256 [S] 423 No such article in this group
Example of an invalid range:
Example of an invalid range:
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] OVER 3000444-3000222
[S] 423 Empty range
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] OVER 3000444-3000222 [S] 423 Empty range
Example of an unsuccessful retrieval of overview information by number because no newsgroup was selected first:
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
[Assumes currently selected newsgroup is invalid.] [C] OVER [S] 412 No newsgroup selected
Feather Standards Track [Page 80] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 80] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Example of an attempt to retrieve information when the currently selected newsgroup is empty:
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 No current article selected
8.4. LIST OVERVIEW.FMT
8.4. LIST OVERVIEW.FMT
8.4.1. Usage
8.4.1. Usage
Indicating capability: OVER
Indicating capability: OVER
Syntax
LIST OVERVIEW.FMT
Syntax LIST OVERVIEW.FMT
Responses
215 Information follows (multi-line)
Responses 215 Information follows (multi-line)
8.4.2. Description
8.4.2. Description
See Section 7.6.1 for general requirements of the LIST command.
See Section 7.6.1 for general requirements of the LIST command.
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:
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:
Subject:
From:
Date:
Message-ID:
References:
:bytes
:lines
Subject: From: Date: Message-ID: References: :bytes :lines
For compatibility with existing implementations, the last two lines MAY instead be:
For compatibility with existing implementations, the last two lines MAY instead be:
Bytes:
Lines:
Bytes: Lines:
even though they refer to metadata, not headers.
even though they refer to metadata, not headers.
Feather Standards Track [Page 81] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 81] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
All subsequent lines MUST consist of either a header name followed by ":full", or the name of a piece of metadata.
All subsequent lines MUST consist of either a header name followed by ":full", or the name of a piece of metadata.
There are no leading or trailing spaces in the output.
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.
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.
This command MAY generate different results if it is used more than once in a session.
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.
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.
8.4.3. Examples
8.4.3. Examples
Example of LIST OVERVIEW.FMT output corresponding to the example OVER output above, in the preferred format:
Example of LIST OVERVIEW.FMT output corresponding to the example OVER output above, in the preferred format:
[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 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] .
Feather Standards Track [Page 82] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 82] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Example of LIST OVERVIEW.FMT output corresponding to the example OVER output above, in the alternative format:
Example of LIST OVERVIEW.FMT output corresponding to the example OVER output above, in the alternative format:
[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 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] .
8.5. HDR
8.5. HDR
8.5.1. Usage
8.5.1. Usage
Indicating capability: HDR
Indicating capability: HDR
Syntax
HDR field message-id
HDR field range
HDR field
Syntax HDR field message-id HDR field range HDR field
Responses
Responses
First form (message-id specified)
225 Headers follow (multi-line)
430 No article with that message-id
First form (message-id specified) 225 Headers follow (multi-line) 430 No article with that message-id
Second form (range specified)
225 Headers follow (multi-line)
412 No newsgroup selected
423 No articles in that range
Second form (range specified) 225 Headers follow (multi-line) 412 No newsgroup selected 423 No articles in that range
Third form (current article number used)
225 Headers follow (multi-line)
412 No newsgroup selected
420 Current article number is invalid
Third form (current article number used) 225 Headers follow (multi-line) 412 No newsgroup selected 420 Current article number is invalid
Parameters
field Name of field
range Number(s) of articles
message-id Message-id of article
Parameters field Name of field range Number(s) of articles message-id Message-id of article
Feather Standards Track [Page 83] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 83] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
8.5.2. Description
8.5.2. Description
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.
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.
The required field argument is the name of a header with the colon omitted (e.g., "subject") or the name of a metadata item including the leading colon (e.g., ":bytes"), and is case insensitive.
The required field argument is the name of a header with the colon omitted (e.g., "subject") or the name of a metadata item including the leading colon (e.g., ":bytes"), and is case insensitive.
The message-id argument indicates a specific article. The range argument may be any of the following:
The message-id argument indicates a specific article. The range argument may be any of the following:
o An article number.
o An article number.
o An article number followed by a dash to indicate all following.
o An article number followed by a dash to indicate all following.
o An article number followed by a dash followed by another article
number.
o An article number followed by a dash followed by another article number.
If neither is specified, the current article number is used.
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.
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.
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.
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.
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.)
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.)
Feather Standards Track [Page 84] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 84] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
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.
Note the distinction between headers and metadata appearing to have the same meaning. Headers are always taken unchanged from the article; metadata are always calculated. For example, a request for "Lines" returns the contents of the "Lines" header of the specified articles, if any, no matter whether they accurately state the number of lines, while a request for ":lines" returns the line count metadata, which is always the actual number of lines irrespective of what any header may state.
If the requested header is not present in the article, or if it is present but empty, a line for that article is included in the output, but the header content portion of the line is empty (the space after the article number MAY be retained or omitted). If the header occurs in a given article more than once, only the content of the first occurrence is returned by HDR. If any article number in the provided range does not exist in the group, no line for that article number is included in the output.
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.
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.
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.
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.
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.
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.
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.
Feather Standards Track [Page 85] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 85] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
8.5.3. Examples
8.5.3. Examples
Example of a successful retrieval of subject lines from a range of articles (3000235 has no Subject header, and 3000236 is missing):
Example of a successful retrieval of subject lines from a range of articles (3000235 has no Subject header, and 3000236 is missing):
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HDR Subject 3000234-3000238
[S] 225 Headers follow
[S] 3000234 I am just a test article
[S] 3000235
[S] 3000237 Re: I am just a test article
[S] 3000238 Ditto
[S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR 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] .
Example of a successful retrieval of line counts from a range of articles:
Example of a successful retrieval of line counts from a range of articles:
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HDR :lines 3000234-3000238
[S] 225 Headers follow
[S] 3000234 42
[S] 3000235 5
[S] 3000237 11
[S] 3000238 2378
[S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR :lines 3000234-3000238 [S] 225 Headers follow [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:
Example of a successful retrieval of the subject line from an article by message-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 Header information follows [S] 0 I am just a test article [S] .
Example of a successful retrieval of the subject line from the current article:
Example of a successful retrieval of the subject line from the current article:
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] HDR subject
[S] 225 Header information follows
[S] 3000234 I am just a test article
[S] .
[C] GROUP misc.test [S] 211 1234 3000234 3002322 misc.test [C] HDR subject [S] 225 Header information follows [S] 3000234 I am just a test article [S] .
Feather Standards Track [Page 86] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 86] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Example of an unsuccessful retrieval of a header from an article by message-id:
Example of an unsuccessful retrieval of a header from an article by message-id:
[C] HDR subject <i.am.not.there@example.com>
[S] 430 No Such Article Found
[C] HDR subject <i.am.not.there@example.com> [S] 430 No Such Article Found
Example of an unsuccessful retrieval of headers from articles by number because no newsgroup was selected first:
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
[Assumes currently selected newsgroup is invalid.] [C] HDR subject 300256- [S] 412 No newsgroup selected
Example of an unsuccessful retrieval of headers because the currently selected newsgroup is empty:
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 No articles in that range
Example of an unsuccessful retrieval of headers because the server does not allow HDR commands for that header:
Example of an unsuccessful retrieval of headers because the server does not allow HDR commands for that header:
[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 not permitted on Content-Type
8.6. LIST HEADERS
8.6. LIST HEADERS
8.6.1. Usage
8.6.1. Usage
Indicating capability: HDR
Indicating capability: HDR
Syntax
LIST HEADERS [MSGID|RANGE]
Syntax LIST HEADERS [MSGID|RANGE]
Responses
215 Field list follows (multi-line)
Responses 215 Field list follows (multi-line)
Parameters
MSGID Requests list for access by message-id
RANGE Requests list for access by range
Parameters MSGID Requests list for access by message-id RANGE Requests list for access by range
Feather Standards Track [Page 87] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 87] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
8.6.2. Description
8.6.2. Description
See Section 7.6.1 for general requirements of the LIST command.
See Section 7.6.1 for general requirements of the LIST command.
The LIST HEADERS command returns a list of fields that may be retrieved using the HDR command.
The LIST HEADERS command returns a list of fields that may be retrieved using the HDR command.
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).
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).
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.
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.
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:
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:
o If the MSGID argument is specified, the results MUST be those
available for the first form of the HDR command.
o If the MSGID argument is specified, the results MUST be those available for the first form of the HDR command.
o If the RANGE argument is specified, the results MUST be those
available for the second and third forms of the HDR command.
o If the RANGE argument is specified, the results MUST be those available for the second and third forms of the HDR command.
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 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).
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 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.
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.
Feather Standards Track [Page 88] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 88] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
8.6.3. Examples
8.6.3. Examples
Example of an implementation providing access to only a few headers:
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 headers supported: [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:
Example of an implementation providing access to the same fields as the first example in Section 8.4.3:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] OVER
[S] HDR
[S] LIST ACTIVE NEWSGROUPS HEADERS OVERVIEW.FMT
[S] .
[C] LIST HEADERS
[S] 215 headers and metadata items supported:
[S] Date
[S] Distribution
[S] From
[S] Message-ID
[S] References
[S] Subject
[S] Xref
[S] :bytes
[S] :lines
[S] .
[C] CAPABILITIES [S] 101 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] .
Example of an implementation providing access to all headers:
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 metadata items supported: [S] : [S] :lines [S] :bytes [S] :x-article-number [S] .
Feather Standards Track [Page 89] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 89] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Example of an implementation distinguishing the first form of the HDR command from the other two forms:
Example of an implementation distinguishing the first form of the HDR command from the other two forms:
[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 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] .
Note that :x-article-number does not appear in the last set of output.
Note that :x-article-number does not appear in the last set of output.
9. Augmented BNF Syntax for NNTP
9. Augmented BNF Syntax for NNTP
9.1. Introduction
9.1. Introduction
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.
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.
Feather Standards Track [Page 90] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 90] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
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.
Between them, the non-terminals <command-line>, <command-datastream>, <command-continuation>, and <response> specify the text that flows between client and server. A consistent naming scheme is used in this document for the non-terminals relating to each command, and SHOULD be used by the specification of registered extensions.
For each command, the sequence is as follows:
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 The client sends an instance of <command-line>; the syntax for the EXAMPLE command is <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 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 The server sends an instance of <response>.
o The server sends an instance of <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>.
* 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>.
* 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>.
* 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>.
o While the latest response is one that indicates more data is
required (in general, a 3xx response):
o While the latest response is one that indicates more data is required (in general, a 3xx response):
* the client sends an instance of <command-continuation>; the
syntax for the EXAMPLE continuation following a 333 response is
<example-333-continuation>;
* the client sends an instance of <command-continuation>; the syntax for the EXAMPLE continuation following a 333 response is <example-333-continuation>;
* the server sends another instance of <response>, as above.
* the server sends another instance of <response>, as above.
(There are no commands in this specification that immediately stream data, but this non-terminal is defined for the convenience of extensions.)
(There are no commands in this specification that immediately stream data, but this non-terminal is defined for the convenience of extensions.)
Feather Standards Track [Page 91] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 91] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
9.2. Commands
9.2. Commands
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).
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 = command EOL
command = X-command
X-command = keyword *(WS token)
command-line = command EOL command = X-command X-command = keyword *(WS token)
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 =/ 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
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]
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]
Feather Standards Track [Page 92] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 92] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
post-command = "POST"
quit-command = "QUIT"
stat-command = "STAT" [WS article-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
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
9.3. Command Continuation
9.3. Command Continuation
This syntax defines the further material sent by the client in the case of multi-stage commands and those that stream data.
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-datastream = UNDEFINED ; not used, provided as a hook for extensions command-continuation = ihave-335-continuation / post-340-continuation
ihave-335-continuation = encoded-article
post-340-continuation = encoded-article
ihave-335-continuation = encoded-article post-340-continuation = encoded-article
encoded-article = multi-line-data-block
; after undoing the "dot-stuffing", this MUST match <article>
encoded-article = multi-line-data-block ; after undoing the "dot-stuffing", this MUST match <article>
9.4. Responses
9.4. Responses
9.4.1. Generic Responses
9.4.1. Generic Responses
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>.
This syntax defines the non-terminal <response>, which represents the generic form of responses; that is, what is sent from the server to the client in response to a <command> or a <command-continuation>.
response = simple-response / multi-line-response
simple-response = initial-response-line
multi-line-response = initial-response-line multi-line-data-block
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)
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)
Feather Standards Track [Page 93] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 93] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
response-argument = 1*A-CHAR
trailing-comment = *U-CHAR
response-argument = 1*A-CHAR trailing-comment = *U-CHAR
9.4.2. Initial Response Line Contents
9.4.2. Initial Response Line Contents
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.
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.
initial-response-content =/ response-111-content /
response-211-content /
response-220-content /
response-221-content /
response-222-content /
response-223-content /
response-401-content
initial-response-content =/ response-111-content / response-211-content / response-220-content / response-221-content / response-222-content / response-223-content / response-401-content
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 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
9.4.3. Multi-line Response Contents
9.4.3. Multi-line Response Contents
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.
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 / 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
article-220-ml-content = article
body-222-ml-content = body
capabilities-101-ml-content = version-line CRLF
article-220-ml-content = article body-222-ml-content = body capabilities-101-ml-content = version-line CRLF
Feather Standards Track [Page 94] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 94] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
*(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)
*(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
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
9.5. Capability Lines
9.5. Capability Lines
This syntax defines the generic form of a capability line in the capabilities list (see Section 3.3.1).
This syntax defines the generic form of a capability line in the capabilities list (see Section 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
capability-line = capability-entry capability-entry = X-capability-entry X-capability-entry = capability-label *(WS capability-argument) capability-label = keyword capability-argument = token
This syntax defines the specific capability entries for the capabilities in this specification.
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
capability-entry =/ hdr-capability / ihave-capability / implementation-capability / list-capability / mode-reader-capability / newnews-capability / over-capability / post-capability / reader-capability
hdr-capability = "HDR"
ihave-capability = "IHAVE"
implementation-capability = "IMPLEMENTATION" *(WS token)
hdr-capability = "HDR" ihave-capability = "IHAVE" implementation-capability = "IMPLEMENTATION" *(WS token)
Feather Standards Track [Page 95] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 95] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
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"
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
version-line = "VERSION" 1*(WS version-number) version-number = nzDIGIT *5DIGIT
9.6. LIST Variants
9.6. LIST Variants
This section defines more specifically the keywords for the LIST command and the syntax of the corresponding response contents.
This section defines more specifically the keywords for the LIST command and the syntax of the corresponding response contents.
; active
list-arguments =/ "ACTIVE" [WS wildmat]
list-content =/ list-active-content
list-active-content = active-groups-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
; 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
; 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)
; 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 =
; newsgroups list-arguments =/ "NEWSGROUPS" [WS wildmat] list-content =/ list-newsgroups-content list-newsgroups-content =
Feather Standards Track [Page 96] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 96] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
*(newsgroup-name WS newsgroup-description CRLF)
newsgroup-description = S-TEXT
*(newsgroup-name WS newsgroup-description CRLF) newsgroup-description = 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)
; 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)
9.7. Articles
9.7. Articles
This syntax defines the non-terminal <article>, which represents the format of an article as described in Section 3.6.
This syntax defines the non-terminal <article>, which represents the format of an article as described in Section 3.6.
article = 1*header CRLF body
header = header-name ":" [CRLF] SP header-content CRLF
header-content = *(S-CHAR / [CRLF] WS)
body = *(*B-CHAR CRLF)
article = 1*header CRLF body header = header-name ":" [CRLF] SP header-content CRLF header-content = *(S-CHAR / [CRLF] WS) body = *(*B-CHAR CRLF)
9.8. General Non-terminals
9.8. General Non-terminals
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.
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
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
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 /
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 /
Feather Standards Track [Page 97] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 97] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
UTF8-non-ascii ; exclude ! * , ? [ \ ]
wildmat-wild = "*" / "?"
UTF8-non-ascii ; exclude ! * , ? [ \ ] wildmat-wild = "*" / "?"
base64 = *(4base64-char) [base64-terminal]
base64-char = UPPER / LOWER / DIGIT / "+" / "/"
base64-terminal = 2base64-char "==" / 3base64-char "="
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 "."
; 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)
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.
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.
Feather Standards Track [Page 98] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 98] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Implementations MUST accept any content that meets this syntax:
Implementations MUST accept any content that meets this syntax:
S-CHAR = %x21-FF
S-NONTAB = CTRL / SP / S-CHAR
S-TEXT = (CTRL / S-CHAR) *B-CHAR
S-CHAR = %x21-FF S-NONTAB = CTRL / SP / S-CHAR S-TEXT = (CTRL / S-CHAR) *B-CHAR
and MAY pass such content on unaltered.
and MAY pass such content on unaltered.
When generating new content or re-encoding existing content, implementations SHOULD conform to this syntax:
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
9.9. Extensions and Validation
9.9. Extensions and Validation
The specification of a registered extension MUST include formal syntax that defines additional forms for the following non-terminals:
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>;
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>;
command-datastream
for each new command that immediately streams data;
command-datastream for each new command that immediately streams data;
command-continuation
for each new command that sends further material after the initial
command line - the syntax of each continuation MUST be exactly
what is sent to the server, including any escape mechanisms such
as "dot-stuffing";
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>;
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>;
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 for each new response code that has a multi-line response - the syntax MUST show the response after the lines containing the response code and the terminating octet have been removed and any "dot-stuffing" undone;
capability-entry
for each new capability label - the syntax of each entry MUST be
compatible with the definition of <X-capability-entry>;
capability-entry for each new capability label - the syntax of each entry MUST be compatible with the definition of <X-capability-entry>;
Feather Standards Track [Page 99] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
Feather Standards Track [Page 99] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
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-arguments for each new variant of the LIST command - the syntax of each entry MUST be compatible with the definition of <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コマンドの各新しい変種のためのリスト内容--構文は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 非端末<コマンドライン>、datastreamを命令している<>、<コマンド継続>、<応答>、および<マルチ系列応答内容>はプロトコルに関する基本概念について説明して、いかなる他の規則でも言及されません。
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>は故意に定義されません。
10. Internationalisation Considerations
10. 国際化問題
10.1. Introduction and Historical Situation
10.1. 序論と歴史的な状況
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.
国際化が重要な問題は考えられなかったとき、RFC977[RFC977]は書かれました。 そういうものとして、すべてのコミュニケーションがASCIIにはあって、7ビットのトランスポート層だけを使用すると前提で書かれました、清潔な状態で実装は実際にはほとんどすべて知られている8ビットですが。
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
それ以来、UsenetとNNTPは世界中で広まっています。 言語と文字集合の問題を扱う規格がないとき、国、ニュースグループ階層構造、および個人はさまざまな働きますが、それらのために必ずほかの場所で適切であるというわけではないソリューションを見つけました。 しかし例えば、或るものが彼らの必要性(西欧のISO/IEC8859-1かロシアのKOI-8などの)に適切なデフォルトの8ビットの文字集合を採用して、他のものがヘッダーでASCII(米国-ASCIIか国家の異形のどちらか)を使用した。
Feather Standards Track [Page 100] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[100ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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.
他のものがMIME[RFC2045]とUTF-8の組み合わせのために続かせた記事本文、およびスチール写真の地方の16ビットの文字集合。 メールにおける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ビットの清潔な輸送経路を作動させると予想されるだけであるということです。
10.2. This Specification
10.2. この仕様
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.
この仕様は米国-ASCII[ANSI1986]からUTF-8[RFC3629]までNNTPを広げています。 以下で議論した2つの領域以外に、UTF-8(米国-ASCIIのスーパーセットである)は義務的です、そして、実装はいかなる他のコード化も使用してはいけません。
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 米国-ASCIIにはヘッダー(例えば、“From"か「対象」)の名前があるに違いありません。
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 ヘッダーは米国-ASCIIかコード化がそれに基礎づけたSHOULD使用を評価します、RFC2047など[RFC2047]のように、別のアプローチのような時間が標準化されるまで。 それらが相互運用性問題を引き起こしそうであるので、現在の、そして、8ビットのencodings(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であったならSHOULDを具体化させます。MIMEによると、します。
o Where an article is obtained from an external source, an
implementation MAY pass it on and derive data from it (such as the
o 実装がそれから記事が外部電源から得られるところに、それを移って、データを引き出すかもしれない、(
Feather Standards Track [Page 101] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[101ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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.)
HDRコマンドへの応答)、記事かデータが上記の必要条件を満たしませんが。 実装が正しくそのような記事とデータを移さなければならない、変わりがありません。 彼らは、記事か派生しているデータを変換するか、または再コード化するのを試みてはいけません。 (それにもかかわらず、記事のさらなる調査の後にそうするのが不適当であると考えるなら、クライアントかサーバが、記事を掲示もしませんし、転送もしないのを選ぶかもしれません。)
This requirement affects the ARTICLE (Section 6.2.1), BODY (Section 6.2.3), HDR (Section 8.5), HEAD (Section 6.2.2), IHAVE (Section 6.3.2), OVER (Section 8.3), and POST (Section 6.3.1) commands.
この要件はARTICLE(セクション6.2.1)に影響します、BODY(セクション6.2.3)、HDR(セクション8.5)、HEAD(セクション6.2.2)、IHAVE(セクション6.3.2)、OVER(セクション8.3)、およびポスト(セクション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を許容して、それらはSHOULDです。RFC1036[RFC1036]の後継者が別のアプローチを標準化するまで、米国-ASCIIに制限されてください。 8ビットのencodings SHOULD、それらが相互運用性問題を引き起こしそうであるので、使用されないでください。
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 ニュースグループ記述SHOULDは米国-ASCIIでそうかRFC1036の後継者までのUTF-8が他のコード化アレンジメントを標準化します。 UTF-8 SHOULD NOTを除いて、8ビットをencodingsします。それらが相互運用性問題を引き起こしそうであるので、使用されてください。
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 上記の必要条件を満たさないでも、外部電源からこのデータを得る実装は正しくそれを扱わなければなりません。 実装(特にクライアント)は正しくそのようなデータを扱わなければなりません。
10.3. Outstanding Issues
10.3. 未解決の問題
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のプライマリ使用がRFC1036(ネットニュース記事)に従う記事を伝えるものである間、それは他の形式に使用されます(Appendix Aを見てください)。 したがって、記事形式に関連する国際化問題が関連仕様で扱われるのは、最も適切です。 Netnews記事に関しては、これはRFC1036のあらゆる後継者です。 メールメッセージに関しては、それはRFC2822です[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
ニュースグループ名をUTF-8に制限するのは、完全解ではありません。 新しいニュースグループ名が作成されるか、またはユーザがニュースグループ名を入れるように頼まれるとき、特に、canonicalisationの何らかの体系が、行われる必要があるでしょう。 この仕様は、それを定義するのを試みません。
Feather Standards Track [Page 102] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[102ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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.
canonicalization。 さらなる仕事がこの領域で記事書式仕様に関連して必要です。 そのような仕様が発表されるまで、実装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と共に彼らの実験と互換性がない方法で使用されるとそれらの名前がcanonicalizedされるのを必要とするかもしれないと強く警告されます。
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のプライマリ使用がNetnewsと共にあって、ニュースグループ記述が特に、フォーマットされた記事を通して通常広げられるので、それらに関連する国際化問題がRFC1036のどんな後継者でも扱われるのは、お勧めです。
11. IANA Considerations
11. IANA問題
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と共に始まるラベルは私的使用目的で予約されます、標準化過程かIESGによって承認された実験プロトコルを定義するとき他のすべての名前がRFCの仕様に関連させていると予想されますが。
Different entries in the registry MUST use different capability labels.
登録の異なったエントリーは異なった能力ラベルを使用しなければなりません。
Different entries in the registry MUST NOT use the same command name. For this purpose, variants distinguished by a second or subsequent keyword (e.g., "LIST HEADERS" and "LIST OVERVIEW.FMT") count as different commands. If there is a need for two extensions to use the same command, a single harmonised specification MUST be registered.
登録の異なったエントリーは同じコマンド名を使用してはいけません。 このために、2番目の、または、その後のキーワード(例えば、「リストヘッダー」と「リストOVERVIEW.FMT」)によって区別された異形は異なったコマンドにみなします。 2つの拡大が同じコマンドを使用する必要があれば、ただ一つの合っている仕様を登録しなければなりません。
12. Security Considerations
12. セキュリティ問題
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でセキュリティ制限についてアプリケーション開発者、情報提供者、およびユーザに知らせることになっています。 議論はセキュリティ危険を減少させるためのいくつかの提案をしますが、明らかにされた問題に決定的なソリューションを含んでいません。
Feather Standards Track [Page 103] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[103ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
12.1. Personal and Proprietary Information
12.1. 個人的で独占である情報
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はそれらの記事に保存されるどんな情報も転送するでしょう。 このドキュメントのこの範囲の外にその情報の仕様がありますが、何らかの個人的な、そして/または、独占である情報がそれらの記事のいくつかで利用可能であることは、ありそうです。 デザイナーとimplementersが有益な警告をユーザに提供するのが、非常に重要であるので、自動的に記事(例えば、ヘッダーの)に追加される材料の中の個人的な、そして/または、独占である情報はうっかり明らかにされません。 さらに、ニュース記事SHOULDの分配を管理する有効で容易に理解されているメカニズムをNNTP Server管理者に提供して、したがって、彼らが、自信をもっていずれのありそうな普及が特定であると報告できるのがニュース記事をセットしました。
12.2. Abuse of Server Log Information
12.2. サーバログ情報の乱用
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.
サーバがそれらの興味深い読書パターンか対象を特定するかもしれないユーザの要求に関するセッションデータを保存する立場にあります。 この情報は明確に現実に秘密です、そして、ある一定の国で法で取り扱いは抑制できます。 そのような材料がどんな発行された結果で身元保証可能な個人の許可なしでも分配されないのを確実にするのにデータを提供するのにこのプロトコルを使用している人々は責任があります。
12.3. Weak Authentication and Access Control
12.3. 弱い認証とアクセスコントロール
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サーバへのプロキシを通して接続する前に認証を必要とするプロキシサーバは適所に置くことができました。
12.4. DNS Spoofing
12.4. DNSスプーフィング
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
多くの既存のNNTP実装が、ローカルの構成ファイルで与えられたドメイン名のリストのDNSルックアップで得られたIPアドレスに対してその接続のIPアドレスをチェックすることによって、接続要求を認可します。 このタイプの認証を使用するサーバとサーバー名のDNSルックアップをすることによってサーバを見つけるクライアントは、非常に大いにDomain Name Serviceを当てにして、その結果、当てにします。
Feather Standards Track [Page 104] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[104ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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.
一般に、IPアドレスとDNS名の慎重なmisassociationに基づくセキュリティー攻撃に、傾向があります。 クライアントとサーバは、IP数/DNS名前協会の継続する正当性を仮定するのにおいて用心深い必要があります。
In particular, NNTP clients and servers SHOULD rely on their name resolver for confirmation of an IP number/DNS name association, rather than cache the result of previous host name lookups. Many platforms already can cache host name lookups locally when appropriate, and they SHOULD be configured to do so. It is proper for these lookups to be cached, however, only when the TTL (Time To Live) information reported by the name server makes it likely that the cached information will remain useful.
特に、NNTPクライアントとサーバSHOULDはIP数/DNS名前協会の確認のために前のホスト名ルックアップの結果をキャッシュするよりむしろ彼らのネーム・リゾルバに頼ります。 多くのプラットホーム、既に適切であるときにキャッシュホストが局所的にルックアップと命名する缶、およびそれら、SHOULD、そうするには、構成されてください。 キャッシュされた情報が役に立ったままで残っているのがネームサーバによって報告されたTTL(時間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情報を観測しなければなりません。 以前にアクセスされたサーバのIPアドレスが変化するとき、NNTPクライアントかサーバがこの規則を守らないなら、それらは偽造されるかもしれません。 ネットワークの番号を付け替えるのがますます一般的になると予想されるのに従って、この形式の攻撃の可能性は増加するでしょう。 その結果、この要件を観測すると、この潜在的セキュリティの脆弱性は減少します。
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名を使用することでクライアントの負荷分散のふるまいを改良して、その戦略を使用するサイトにアクセスする際にユーザが失敗を経験するという見込みを減少させます。
12.5. UTF-8 Issues
12.5. UTF-8問題
UTF-8 [RFC3629] permits only certain sequences of octets and designates others as either malformed or "illegal". The Unicode standard identifies a number of security issues related to illegal sequences and forbids their generation by conforming implementations.
UTF-8[RFC3629]は八重奏のある系列だけを可能にして、奇形か「不法である」として他のものを任命します。 ユニコード規格は、不法な系列に関連する多くの安全保障問題を特定して、実装を従わせることによって、彼らの世代を禁じます。
Implementations of this specification MUST NOT generate malformed or illegal sequences and SHOULD detect them and take some appropriate action. This could include the following:
この仕様の実装が奇形の、または、不法な系列を生成してはいけなくて、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 系列%xEF.BF.BDにそのような系列を置き換えます。(xEF.BF.BDは「交換キャラクタ」U+FFFDをコード化します)。
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コード化の特性に基づいている)にそのような系列を置き換えます。
Feather Standards Track [Page 105] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[105ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
In the last case, the implementation MUST ensure that any replacement cannot be used to bypass validity or security checks. For example, the illegal sequence %xC0.A0 is an over-long encoding for space (%x20). If it is replaced by the correct encoding in a command line, this needs to happen before the command line is parsed into individual arguments. If the replacement came after parsing, it would be possible to generate an argument with an embedded space, which is forbidden. Use of the "replacement character" does not have this problem, since it is permitted wherever non-US-ASCII characters are. Implementations SHOULD use one of the first two solutions where the general structure of the NNTP stream remains intact and SHOULD close the connection if it is no longer possible to parse it sensibly.
最後の場合では、実装は、正当性かセキュリティチェックを迂回させるのに少しの交換も使用できないのを確実にしなければなりません。 例えば、不法な系列%xC0.A0はスペース(%x20)のための過剰長いコード化です。 それをコマンドラインでの正しいコード化に取り替えるなら、これは、コマンドラインが個々の議論に分析される前に起こる必要があります。 交換が構文解析に続いているなら、禁じられる埋め込まれたスペースとの議論を生成するのは可能でしょうに。 それがどこでも、非米国のASCII文字がいるところで受入れられるので、「交換キャラクタ」の使用には、この問題がありません。 実装SHOULDはNNTPストリームの一般構造体が元の状態のままになって、分別よくそれを分析するのがもう可能でないならSHOULDが接続を終える最初の2つのソリューションの1つを使用します。
12.6. Caching of Capability Lists
12.6. ケイパビリティ・リストのキャッシュ
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:
例えば、暗号化されたリンクにおけるcleartextパスワードの使用を可能にするサーバを考えますが、そうでなければ、考えるというわけではなくなってください:
[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
[セットアップが終了した接続に頭文字をつけてください。] 受入れられた[C]CAPABILITIES[S]101Capabilityを掲示する[S]200NNTP Service Readyが記載します: [S]バージョン2[S]読者[S]NEWNEWS[S]ポスト[S]XENCRYPT[S]LIST ACTIVE NEWSGROUPS[S]XENCRYPT[クライアントとサーバはリンクに関して暗号化を交渉する][S]283Encryptedリンクが設立した[C]
Feather Standards Track [Page 106] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[106ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] NEWNEWS
[S] POST
[S] XSECRET
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] XSECRET fred flintstone
[S] 290 Password for fred accepted
[C] CAPABILITIES[S]101Capabilityは記載します: [S]バージョン2[S]読者[S]NEWNEWS[S]ポスト[S]XSECRET[S]LIST ACTIVE NEWSGROUPS[S][C] fredのためのXSECRET fred flintstone[S]290Passwordは受け入れました。
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
[セットアップが終了した接続に頭文字をつけてください。] 安全なリンクの上に受入れられた受入れられた[C]XSECRET fred flintstone[S]483Onlyを掲示する[S]200NNTP Service Ready
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.
通常、キャッシュは少しのセキュリティやプライバシー拡張子も使用しないで、時間が追加コマンドに必要である匿名のクライアントのために考えられるだけであるはずです、そして、応答はめぼしい問題です。
13. Acknowledgements
13. 承認
This document is the result of much effort by the present and past members of the NNTP Working Group, chaired by Russ Allbery and Ned Freed. It could not have been produced without them.
このドキュメントはラスAllberyとネッド・フリードによってまとめられたNNTP作業部会の現在と過去のメンバーによる多くの取り組みの結果です。 それらなしでそれを生産できませんでした。
The author acknowledges the original authors of NNTP as documented in RFC 977 [RFC977]: Brian Kantor and Phil Lapsey.
作者はRFC977[RFC977]に記録されるようにNNTPの原作者を承認します: ブライアンKantorとフィル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委員会の仕事。 このドキュメントの組織は最後の利用可能なバージョンによってこのワーキンググループから影響を及ぼされました。 気前よく元の機械可読なソースをそのドキュメントに供給するためのエリオットのおかげで特別番組。
Feather Standards Track [Page 107] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[107ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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ワーキンググループ、明確にRFC1869[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 セキュリティの特定の、そして、関連している例を提供するとそれが発行されるので、RFC2616[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 以下の個人によってこのドキュメントの先祖のより多くのひとりを準備するのに提供されたコメントと追加情報:
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>
ラス Allbery <rra@stanford.edu 、gt;、ウェイン Davison <davison@armory.com 、gt;、クリスルイス<clewis@bnr.ca>トム Limoncelli <tal@mars.superlink.net 、gt;、エリックSchnoebelen<eric@egsner.cirr.com>リッシュ Salz <rsalz@osf.org 、gt。
This work was motivated by the work of various news reader authors and news server authors, including those listed below:
この仕事は様々なニュース読者の作者と以下に記載されたものを含むニュースサーバ作者の仕事で動機づけられました:
Rick Adams
Original author of the NNTP extensions to the RN news reader and
last maintainer of Bnews.
RNニュース読者へのNNTP拡張子のリックアダムスOriginal作者とBnewsの最後の維持装置。
Stan Barber
Original author of the NNTP extensions to the news readers that
are part of Bnews.
Bnewsの一部であるニュース読者へのNNTP拡張子のスタンバーバーOriginal作者。
Geoff Collyer
Original author of the OVERVIEW database proposal and one of the
original authors of CNEWS.
OVERVIEWデータベース提案のジェフCollyer Original作者とCNEWSの原作者のひとり。
Dan Curry
Original author of the xvnews news reader.
xvnewsニュース読者のダンCurry Original作者。
Wayne Davison
Author of the first threading extensions to the RN news reader
(commonly called TRN).
RNニュース読者(一般的にTRNと呼ばれる)への最初の縫うように通る拡大のウェインデイヴィソンAuthor。
Geoff Huston
Original author of ANU NEWS.
ANU NEWSのジェフヒューストンOriginal作者。
Feather Standards Track [Page 108] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[108ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Phil Lapsey
Original author of the UNIX reference implementation for NNTP.
NNTPのためのUNIX参照実装のフィルLapsey Original作者。
Iain Lea
Original maintainer of the TIN news reader.
TINニュース読者のイアンLea Original維持装置。
Chris Lewis
First known implementer of the AUTHINFO GENERIC extension.
AUTHINFO GENERIC拡張子がより多くのimplementerに知られているクリスルイスFirst。
Rich Salz
Original author of INN.
ザルツOriginalが書くINNの金持ち。
Henry Spencer
One of the original authors of CNEWS.
CNEWSの原作者のヘンリースペンサー1つ。
Kim Storm
Original author of the NN news reader.
NNニュース読者のキムStorm Original作者。
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
マッチアスAndreeグレッグAndrukダニエルバークレーマウリジオコドーニョマーククリスピンアンドリューGierthユルゲンHelbingスコットHollenbeckウルスジャンセンチャールズリンジーアデロベットデヴィッドマグダケンマーチソンフランソアPetillonピーター・ロビンソンロブSiemborskiハワードSwinehartルドルフスバントウルジェフリーVinocurエリックWarmelink
The author thanks them all and apologises to anyone omitted.
彼らに皆、感謝します、そして、作者は省略された人はだれにも謝ります。
Finally, the present author gratefully acknowledges the vast amount of work put into previous versions by the previous author:
最終的に、現在の作者は感謝して前の作者によって旧バージョンに入れられた広大な仕事量を承認します:
Stan Barber <sob@academ.com>
スタン Barber <sob@academ.com 、gt。
Feather Standards Track [Page 109] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[109ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[ANSI1986] American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[ANSI1986]American National Standards Institut、「7コード化文字集合--ビット、情報交換用米国標準コード、」、ANSI X3.4、1986
[RFC977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
[RFC977] カンターとB.とP.ラプスリー、「ネットワークの電子情報を転送するプロトコル」、RFC977、1986年2月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
エド[RFC4234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson、2006年10月のS.、「Base16、Base32、およびBase64データEncodings」RFC4648。
[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月。」
14.2. Informative References
14.2. 有益な参照
[NNTP-AUTH] Vinocur, J., Murchison, K., and C. Newman, "Network
News Transfer Protocol (NNTP) Extension for
Authentication",
RFC 4643, October 2006.
[NNTP-AUTH] Vinocur、J.、マーチソン、K.、およびC.ニューマン、「認証のためのネットワークの電子情報を転送するプロトコル(NNTP)拡大」、RFC4643、2006年10月。
[NNTP-STREAM] Vinocur, J. and K. Murchison, "Network News Transfer
Protocol (NNTP) Extension for Streaming Feeds",
RFC 4644, October 2006.
[NNTP-ストリーム] VinocurとJ.とK.マーチソン、「ストリーミングの給送のためのネットワークの電子情報を転送するプロトコル(NNTP)拡大」、RFC4644、2006年10月。
Feather Standards Track [Page 110] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[110ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
[NNTP-TLS] Murchison, K., Vinocur, J., and C. Newman, "Using
Transport Layer Security (TLS) with Network News
Transfer Protocol (NNTP)", RFC 4642, October 2006.
[NNTP-TLS] マーチソン、K.、Vinocur、J.、およびC.ニューマン、「ネットニュースがあるトランスポート層セキュリティ(TLS)を使用して、プロトコル(NNTP)を移してください」、RFC4642、2006年10月。
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987.
[RFC1036] ホートンとM.とR.アダムス、「USENETメッセージの置き換えの規格」、RFC1036、1987年12月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[RFC1305] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
November 1995.
[RFC1869]KlensinとJ. N.と解放されて、ローズとM.とStefferud、E.とD.クロッカー、「SMTPサービス拡張子」、STD10、RFC1869、1995年11月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
M. [RFC2629]ローズ、RFC2629、「XMLを使用することでI-DsとRFCsに書く」6月1999日
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, October
2000.
[RFC2980] バーバー、S.、「一般的なNNTP拡張子」、RFC2980、2000年10月。
[ROBE1995] Robertson, R., "FAQ: Overview database / NOV General
Information", January 1995.
[ROBE1995]ロバートソン、R.、「FAQ:」 1995年1月の「概要データベース/11月の総合案内。」
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記事<ニュース: nov-faq-1-930909720@agate.Berkeley.EDU として掲示された、gt。
[SALZ1992] Salz, R., "Manual Page for wildmat(3) from the INN 1.4
distribution, Revision 1.10", April 1992.
[SALZ1992]ザルツ、R.、「INN1.4分配からのwildmat(3)、Revisionのための手動のパージュ、1.1インチと、1992インチ年4月。
There is no definitive copy of this document known to
the author.
作者にとって知られているこのドキュメントをどんな決定的なコピーもありません。
Feather Standards Track [Page 111] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[111ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Appendix A. Interaction with Other Specifications
他の仕様との付録A.相互作用
NNTP is most often used for transferring articles that conform to RFC 1036 [RFC1036] (such articles are called "Netnews articles" here). It is also sometimes used for transferring email messages that conform to RFC 2822 [RFC2822] (such articles are called "email articles" here). In this situation, articles must conform both to this specification and to that other one; this appendix describes some relevant issues.
NNTPは、RFC1036[RFC1036]に従う記事を移すのにたいてい使用されます(そのような記事はここに「ネットニュース記事」と呼ばれます)。 また、それは、RFC2822[RFC2822]に従うメールメッセージを移すのに時々使用されます(そのような記事はここに「メール記事」と呼ばれます)。 この状況で、記事は他の様々な仕様に従わなければなりません。 この付録はいくつかの当該の問題について説明します。
A.1. Header Folding
A.1。 ヘッダーの折り重なり
NNTP allows a header line to be folded (by inserting a CRLF pair) before any space or TAB character.
NNTPは、ヘッダー系列がどんなスペースや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.
メールとNetnews記事の両方が、それぞれのヘッダー系列にスペースかTAB以外の少なくとも1つの八重奏を持つのに必要です。 したがって、折り重なりは1ポイントで連続した空間かTABsの各系列で起こることができるだけです。 ネットニュース記事がすべて最初の系列にヘッダー名、コロン、および次のスペースを持つのにさらに必要です。 折り重なりはそのスペースを超えて起こるだけであるかもしれません。 最終的に、何らかの非の従うソフトウェアが系列から引きずっている空間とTABsを取り外すでしょう。 したがって、スペースかTABの後にヘッダーを折り重ねるのは勧められないかもしれません。
For maximum safety, header lines SHOULD conform to the following syntax rather than to that in Section 9.7.
最大の安全、SHOULDがセクション9.7におけるそれにというよりむしろ以下の構文に従わせるヘッダー系列のために。
header = header-name ":" SP [header-content] CRLF
header-content = [WS] token *( [CRLF] WS token )
「ヘッダー=ヘッダー名」:、」 SP[ヘッダー含有量]CRLFヘッダー含有量は[WS]トークン*と等しいです。([CRLF]WSトークン)
A.2. Message-IDs
A.2。 メッセージID
Every article handled by an NNTP server MUST have a unique message-id. For the purposes of this specification, a message-id is an arbitrary opaque string that merely needs to meet certain syntactic requirements and is just a way to refer to the article.
NNTPサーバによって扱われたあらゆる記事がユニークなメッセージイドを持たなければなりません。 この仕様の目的のために、メッセージイドはある構文の必要条件を満たすのが単に必要であり、ただ記事を参照する方法である任意の不透明なストリングです。
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システムに再注入されて、RFC1036[RFC1036]は、メッセージイドが時間中にグローバルにユニークであることを必要とします。
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:
そして、この仕様が、メッセージイドが同じであると述べる、八重奏の同じ系列から成る場合にだけ。 他の仕様は特定のキャラクタに解釈を置いているので等しいと2つの異なった系列を定義するかもしれません。 RFC2822[RFC2822]には、「引用され」て「逃げられた」キャラクタの概念があります。 したがって、それは3つのメッセージイドを考えます:
Feather Standards Track [Page 112] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[112ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
<ab.cd@example.com>
<"ab.cd"@example.com>
<"ab.\cd"@example.com>
<ab.cd@example.com><"ab.cd"@example.com><「腹筋\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コマンドの結果をチェックする時のように。 RFC1036[RFC1036]が2個の異なったストリングを同じであるとして決して扱わないことに注意してください。 後継者(書くことの時間現在の間の)がメッセージイドの構文を制限するので、RFC2822が同等な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.
この仕様は記事のメッセージイドがどう決定しているかを説明しません。 それを記事のコンテンツから推論するか、または外部電源から得るかもしれません。 また、サーバがこれとのコンパチブルメッセージイドの定義を含む別の仕様に従っているなら、サーバSHOULDはそれらのメッセージイドを使用します。 コモンにアプローチします、そして、ヘッダーのコンテンツからのメッセージイドを抜粋するSHOULDをメールとNetnews記事に使用されて、いる人が「Message 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コマンドで記事を得ると、コマンドが提供されたメッセージイドがあるでしょう。 サーバは、記事コンテンツからそれを使用するか、または1を決定するかもしれません。 そうします、それ。しかしながら、どれでも、SHOULDは、IHAVEコマンドが同じ議論と記事で繰り返されるとそれが写しとして認識されるのを確実にします。
If an article does not contain a message-id that the server can identify, it MUST synthesize one. This could, for example, be a simple sequence number or be based on the date and time when the article arrived. When email or Netnews articles are handled, a Message-ID header SHOULD be added to ensure global consistency and uniqueness.
記事がサーバが特定できるメッセージイドを含んでいないなら、それは1つを統合しなければなりません。 これは、例えば、簡単な一連番号であるか記事が到着した日時に基づくことができました。 メールかNetnews記事が扱われたa 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ヘッダーから得られていないかもしれないので以下の例が正統であることに(珍しいのですが)注意してください:
Feather Standards Track [Page 113] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[113ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
[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 、gt;、[S]221 0 <45223423@example.com 、gt;、[S]経路: pathost!デモ!サクランボを載せたバニラアイス!メールでない[S]メッセージID: <1234@example.net>[S]From: 「デモユーザ、「 <nobody@example.net 、gt;、[S]ニュースグループ:、」 ミスクテスト[S]Subject: 私はただテスト記事[S]日付:です。 1998年10月6日の04:38:40 -0500[S]組織: 例のネットの、そして、不確実なテキサス[S]。
A.3. Article Posting
A.3。 記事任命
As far as NNTP is concerned, the POST and IHAVE commands provide the same basic facilities in a slightly different way. However, they have rather different intentions.
NNTPに関する限り、ポストと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サーバのシステムの間に良品を伝えるために意図します、また、すべての記事が恐らく別の仕様に従っていて(例えばすべての記事がNetnews記事です)。 クライアントが既にどんな必要な合法化もしてしまうだろうと予想される、(または、それはそうした第三者から記事を順番に得ました)、。 したがって、左が変わりがなかったなら、SHOULDを満足させます。
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.
エンドユーザがそのようなaシステムに新たに作成された記事を注いでいるとき、対照的に、ポストコマンドは使用のために意図します。 移される記事は、従うメールかNetnews記事でないかもしれません、そして、サーバがそれを有効にすると予想されて、必要なら、それを右に変換するのは前方の分配のために形成されます。 別々のソフトウェア一本はサーバインストールのときにしばしばこれをします。 そうだとすれば、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.
ポストコマンドはいろいろ失敗できます、そして、クライアントは記事を再送する用意ができているべきです。 しかしながら、そうするとき、サーバ、または他のサーバが、2つの記事が写しであると認めることができるように同じメッセージイドが両方の試みに割り当てられるのを保証するのは(できるだけ)しばしば重要です。 メールかNetnews記事の場合、したがって、SHOULDが名前「メッセージID」でヘッダーを含んでいるという掲示された記事、およびこのヘッダーSHOULDのコンテンツでは、各試みのときに同じであってください。 サーバSHOULDは、このヘッダーのための同じコンテンツがある2つのPOSTed記事が同じであるとして認識されて、同じメッセージイドが割り当てられるのを確実にします、それらの内容がメッセージイドとして使用に適しているか否かに関係なく。
Feather Standards Track [Page 114] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[114ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Appendix B. Summary of Commands
コマンドの付録B.概要
This section contains a list of every command defined in this document, ordered by command name and by indicating capability.
このセクションはコマンド名と能力を示すことによって注文されたこのドキュメントで定義されたあらゆるコマンドのリストを含みます。
Ordered by command name:
コマンド名で、注文します:
+-------------------+-----------------------+---------------+
| Command | Indicating capability | Definition |
+-------------------+-----------------------+---------------+
| ARTICLE | READER | Section 6.2.1 |
| BODY | READER | Section 6.2.3 |
| CAPABILITIES | mandatory | Section 5.2 |
| DATE | READER | Section 7.1 |
| GROUP | READER | Section 6.1.1 |
| HDR | HDR | Section 8.5 |
| HEAD | mandatory | Section 6.2.2 |
| HELP | mandatory | Section 7.2 |
| IHAVE | IHAVE | Section 6.3.2 |
| LAST | READER | Section 6.1.3 |
| LIST | LIST | Section 7.6.1 |
| LIST ACTIVE.TIMES | LIST | Section 7.6.4 |
| LIST ACTIVE | LIST | Section 7.6.3 |
| LIST DISTRIB.PATS | LIST | Section 7.6.5 |
| LIST HEADERS | HDR | Section 8.6 |
| LIST NEWSGROUPS | LIST | Section 7.6.6 |
| LIST OVERVIEW.FMT | OVER | Section 8.4 |
| LISTGROUP | READER | Section 6.1.2 |
| MODE READER | MODE-READER | Section 5.3 |
| NEWGROUPS | READER | Section 7.3 |
| NEWNEWS | NEWNEWS | Section 7.4 |
| NEXT | READER | Section 6.1.4 |
| OVER | OVER | Section 8.3 |
| POST | POST | Section 6.3.1 |
| QUIT | mandatory | Section 5.4 |
| STAT | mandatory | Section 6.2.4 |
+-------------------+-----------------------+---------------+
+-------------------+-----------------------+---------------+ | コマンド| 能力を示します。| 定義| +-------------------+-----------------------+---------------+ | 記事| 読者| セクション6.2 .1| | ボディー| 読者| セクション6.2 .3| | 能力| 義務的| セクション5.2| | 日付| 読者| セクション7.1| | グループ| 読者| セクション6.1 .1| | HDR| HDR| セクション8.5| | ヘッド| 義務的| セクション6.2 .2| | ヘルプ| 義務的| セクション7.2| | IHAVE| IHAVE| セクション6.3 .2| | 最終| 読者| セクション6.1 .3| | リスト| リスト| セクション7.6 .1| | リストACTIVE.TIMES| リスト| セクション7.6 .4| | リストアクティブです。| リスト| セクション7.6 .3| | リストDISTRIB.PATS| リスト| セクション7.6 .5| | リストヘッダー| HDR| セクション8.6| | リストニュースグループ| リスト| セクション7.6 .6| | リストOVERVIEW.FMT| 終わる| セクション8.4| | LISTGROUP| 読者| セクション6.1 .2| | モード読者| モード読者| セクション5.3| | NEWGROUPS| 読者| セクション7.3| | NEWNEWS| NEWNEWS| セクション7.4| | 次へ| 読者| セクション6.1 .4| | 終わる| 終わる| セクション8.3| | ポスト| ポスト| セクション6.3 .1| | やめてください。| 義務的| セクション5.4| | スタット| 義務的| セクション6.2 .4| +-------------------+-----------------------+---------------+
Feather Standards Track [Page 115] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[115ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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 |
+-------------------+-----------------------+---------------+
+-------------------+-----------------------+---------------+ | コマンド| 能力を示します。| 定義| +-------------------+-----------------------+---------------+ | 能力| 義務的| セクション5.2| | ヘッド| 義務的| セクション6.2 .2| | ヘルプ| 義務的| セクション7.2| | やめてください。| 義務的| セクション5.4| | スタット| 義務的| セクション6.2 .4| | HDR| HDR| セクション8.5| | リストヘッダー| HDR| セクション8.6| | IHAVE| IHAVE| セクション6.3 .2| | リスト| リスト| セクション7.6 .1| | リストアクティブです。| リスト| セクション7.6 .3| | リストACTIVE.TIMES| リスト| セクション7.6 .4| | リストDISTRIB.PATS| リスト| セクション7.6 .5| | リストニュースグループ| リスト| セクション7.6 .6| | モード読者| モード読者| セクション5.3| | NEWNEWS| NEWNEWS| セクション7.4| | 終わる| 終わる| セクション8.3| | リストOVERVIEW.FMT| 終わる| セクション8.4| | ポスト| ポスト| セクション6.3 .1| | 記事| 読者| セクション6.2 .1| | ボディー| 読者| セクション6.2 .3| | 日付| 読者| セクション7.1| | グループ| 読者| セクション6.1 .1| | 最終| 読者| セクション6.1 .3| | LISTGROUP| 読者| セクション6.1 .2| | NEWGROUPS| 読者| セクション7.3| | 次へ| 読者| セクション6.1 .4| +-------------------+-----------------------+---------------+
Feather Standards Track [Page 116] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[116ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Appendix C. Summary of Response Codes
応答コードの付録C.概要
This section contains a list of every response code defined in this document and indicates whether it is multi-line, which commands can generate it, what arguments it has, and what its meaning is.
このセクションは、本書では定義されたあらゆる応答コードのリストを含んでいて、それがマルチ系列であるかどうかと、どのコマンドがそれを生成することができるか、そして、どんな議論を持つか、そして、意味が何であるかを示します。
Response code 100 (multi-line)
Generated by: HELP
Meaning: help text follows.
以下によって生成された応答コード100(マルチ系列の) 意味するのを助けてください: 助けテキストは従います。
Response code 101 (multi-line)
Generated by: CAPABILITIES
Meaning: capabilities list follows.
以下によって生成された応答コード101(マルチ系列の) 能力意味: 能力リストは従います。
Response code 111
Generated by: DATE
1 argument: yyyymmddhhmmss
Meaning: server date and time.
以下による応答コード111Generated DATE1議論: yyyymmddhhmmss Meaning: サーバ日時。
Response code 200
Generated by: initial connection, MODE READER
Meaning: service available, posting allowed.
以下による応答コード200Generated 接続、MODE READER Meaningに頭文字をつけてください: 利用可能なサービス、許された任命。
Response code 201
Generated by: initial connection, MODE READER
Meaning: service available, posting prohibited.
以下による応答コード201Generated 接続、MODE READER Meaningに頭文字をつけてください: 利用可能なサービス、禁止された任命。
Response code 205
Generated by: QUIT
Meaning: connection closing (the server immediately closes the
connection).
以下による応答コード205Generated 意味するのをやめてください: 接続閉鎖(サーバはすぐに、接続を終えます)。
Response code 211
The 211 response code has two completely different forms,
depending on which command generated it:
応答は211応答コードが2つの完全に異なったフォーム、依存を持っているそれのコマンドがそれを生成した211をコード化します:
(not multi-line)
Generated by: GROUP
4 arguments: number low high group
Meaning: group selected.
以下によって生成された(マルチ系列でない) GROUP4議論: 数の低い高いグループMeaning: 選択されていた状態で、分類してください。
(multi-line)
Generated by: LISTGROUP
4 arguments: number low high group
Meaning: article numbers follow.
以下によって生成された(マルチ系列) LISTGROUP4議論: 数の低い高いグループMeaning: 記事番号は従います。
Feather Standards Track [Page 117] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[117ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Response code 215 (multi-line)
Generated by: LIST
Meaning: information follows.
以下によって生成された応答コード215(マルチ系列の) 意味を記載してください: 情報は従います。
Response code 220 (multi-line)
Generated by: ARTICLE
2 arguments: n message-id
Meaning: article follows.
以下によって生成された応答コード220(マルチ系列の) ARTICLE2議論: nメッセージイドMeaning: 記事は従います。
Response code 221 (multi-line)
Generated by: HEAD
2 arguments: n message-id
Meaning: article headers follow.
以下によって生成された応答コード221(マルチ系列の) HEAD2議論: nメッセージイドMeaning: 記事ヘッダーは続きます。
Response code 222 (multi-line)
Generated by: BODY
2 arguments: n message-id
Meaning: article body follows.
以下によって生成された応答コード222(マルチ系列の) BODY2議論: nメッセージイドMeaning: 記事本文は続きます。
Response code 223
Generated by: LAST, NEXT, STAT
2 arguments: n message-id
Meaning: article exists and selected.
以下による応答コード223Generated LAST、ネクスト、STAT2議論: nメッセージイドMeaning: 存在していて、選択された記事。
Response code 224 (multi-line)
Generated by: OVER
Meaning: overview information follows.
以下によって生成された応答コード224(マルチ系列の) 意味の上で: 概要情報は従います。
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.
以下による応答コード235Generated IHAVE(2番目のステージ)意味: 記事はOKを移しました。
Response code 240
Generated by: POST (second stage)
Meaning: article received OK.
以下による応答コード240Generated ポスト(2番目のステージ)意味: 記事はOKを受けました。
Feather Standards Track [Page 118] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[118ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Response code 335
Generated by: IHAVE (first stage)
Meaning: send article to be transferred.
以下による応答コード335Generated IHAVE(第一段階)意味: 記事を送って、移してください。
Response code 340
Generated by: POST (first stage)
Meaning: send article to be posted.
以下による応答コード340Generated ポスト(第一段階)意味: 記事を送って、掲示されてください。
Response code 400
Generic response and generated by initial connection
Meaning: service not available or no longer available (the server
immediately closes the connection).
応答コード400Generic応答で初期の接続Meaningによって発生する: 利用可能でないかもう利用可能でない(サーバはすぐに、接続を終える)サービス。
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.
応答コード401Generic応答1議論: 能力ラベルMeaning: サーバが間違ったモードであります。 示された能力は、モードを変えるのに使用されるべきです。
Response code 403
Generic response
Meaning: internal fault or problem preventing action being taken.
応答コード403Generic応答Meaning: 行動が取られるのを防ぐことにおける内部の欠点か問題。
Response code 411
Generated by: GROUP, LISTGROUP
Meaning: no such newsgroup.
以下による応答コード411Generated LISTGROUPが以下を意味して、分類してください。 そのようなニュースグループでない。
Response code 412
Generated by: ARTICLE, BODY, GROUP, HDR, HEAD, LAST, LISTGROUP,
NEXT, OVER, STAT
Meaning: no newsgroup selected.
以下による応答コード412Generated スタットが以下を意味して、記事、ボディー、グループ、HDRは最後に次の、そして、終わっているLISTGROUPの上に立ちます。 ニュースグループは選択されませんでした。
Response code 420
Generated by: ARTICLE, BODY, HDR, HEAD, LAST, NEXT, OVER, STAT
Meaning: current article number is invalid.
以下による応答コード420Generated 記事、ボディー、HDRは最後、次に、終わっているスタット意味の上に立ちます: 現在の記事番号は無効です。
Response code 421
Generated by: NEXT
Meaning: no next article in this group.
以下による応答コード421Generated 次の意味: このグループにおける次の記事がありません。
Response code 422
Generated by: LAST
Meaning: no previous article in this group.
以下による応答コード422Generated 最後の意味: このグループにおける前の記事がありません。
Response code 423
Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT
Meaning: no article with that number or in that range.
以下による応答コード423Generated 記事、ボディー、HDR、ヘッド、終わっているスタット意味: その数かその範囲で記事がありません。
Feather Standards Track [Page 119] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[119ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Response code 430
Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT
Meaning: no article with that message-id.
以下による応答コード430Generated 記事、ボディー、HDR、ヘッド、終わっているスタット意味: そのメッセージイドがある記事がありません。
Response code 435
Generated by: IHAVE (first stage)
Meaning: article not wanted.
以下による応答コード435Generated IHAVE(第一段階)意味: 欲しくなかった記事。
Response code 436
Generated by: IHAVE (either stage)
Meaning: transfer not possible (first stage) or failed (second
stage); try again later.
以下による応答コード436Generated IHAVE(どちらかのステージ)意味: 可能な(第一段階)ではなく転送か失敗(2番目のステージ)にされる。 後でもう一度試みてください。
Response code 437
Generated by: IHAVE (second stage)
Meaning: transfer rejected; do not retry.
以下による応答コード437Generated IHAVE(2番目のステージ)意味: 拒絶された転送。 再試行しないでください。
Response code 440
Generated by: POST (first stage)
Meaning: posting not permitted.
以下による応答コード440Generated ポスト(第一段階)意味: 任命は可能にしませんでした。
Response code 441
Generated by: POST (second stage)
Meaning: posting failed.
以下による応答コード441Generated ポスト(2番目のステージ)意味: 任命は失敗しました。
Response code 480
Generic response
Meaning: command unavailable until the client has authenticated
itself.
応答コード480Generic応答Meaning: クライアントまで入手できないコマンドはそれ自体を認証しました。
Response code 483
Generic response
Meaning: command unavailable until suitable privacy has been
arranged.
応答コード483Generic応答Meaning: 適当なプライバシーまで入手できないコマンドはアレンジされました。
Response code 500
Generic response
Meaning: unknown command.
応答コード500Generic応答Meaning: 未知のコマンド。
Response code 501
Generic response
Meaning: syntax error in command.
応答コード501Generic応答Meaning: コマンドにおける構文エラー。
Feather Standards Track [Page 120] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[120ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Response code 502
Generic response and generated by initial connection
初期の接続によって502Generic応答をコード化して、生成された応答
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.
応答コード503Generic応答Meaning: サポートされなかった特徴。
Response code 504
Generic response
Meaning: error in base64-encoding [RFC4648] of an argument.
応答コード504Generic応答Meaning: 議論のbase64をコード化している[RFC4648]の誤り。
Appendix D. Changes from RFC 977
RFC977からの付録D.変化
In general every attempt has been made to ensure that the protocol specification in this document is compatible with the version specified in RFC 977 [RFC977] and the various facilities adopted from RFC 2980 [RFC2980]. However, there have been a number of changes, some compatible and some not.
一般に、プロトコル仕様は本書ではRFC977[RFC977]で指定されるバージョンとRFC2980[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 デフォルト文字集合は米国-ASCII[ANSI1986]からUTF-8[RFC3629]に変わります(米国-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 すべての記事がメッセージイドを持つのに必要であり、「<0>」プレースホルダを排除すると、いくつかの応答がRFC977のコネで使用されました。
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 合っている能力が既にRFC977("wildmats"、セクション4)に記録したニュースグループ名は、はっきりさせられて拡張されています。 新しい設備(例えば、コンマと感嘆符の使用)はどこでも、wildmatsがプロトコルに現れるところに許容されています。
o Support for pipelining of commands (Section 3.5) is made
mandatory.
o コマンド(セクション3.5)のパイプライン処理のサポートを義務的にします。
Feather Standards Track [Page 121] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[121ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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.1を見てください。記事付番(セクション6)のための規則がはっきりさせられた、(.1 .2)。
o The SLAVE command (which was ill-defined) is removed from the
protocol.
o プロトコルからSLAVEコマンド(ほとんど定義されていなかった)を取り除きます。
o Four-digit years are permitted in the NEWNEWS (Section 7.4) and
NEWGROUPS (Section 7.3) commands (two-digit years are still
permitted). The optional distribution parameter to these commands
has been removed.
o 4ケタの年はNEWNEWS(セクション7.4)とNEWGROUPS(セクション7.3)コマンドで受入れられます(2ケタの年はまだ受入れられています)。 これらのコマンドへの任意の分配パラメタを取り除いてあります。
o The LIST command (Section 7.6.1) is greatly extended; the original
is available as LIST ACTIVE, while new variants include
ACTIVE.TIMES, DISTRIB.PATS, and NEWSGROUPS. A new "m" status flag
is added to the LIST ACTIVE response.
o LISTコマンド(セクション7.6.1)は大いに広げられます。 オリジナルはLIST ACTIVEとして利用可能です、新しい変種がACTIVE.TIMES、DISTRIB.PATS、およびニュースグループを含んでいますが。新しい「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)はRFC2980から事実上、変わりがない状態で採用されます。
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)はRFC2980から採用されます。 任意の範囲議論は加えられます、そして、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)はRFC2980から採用されました、そして、その意味と効果ははっきりさせられました。
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 RFC2980のXHDRコマンドは新しいHDR(セクション8.5)とLIST HEADERS(セクション8.6)コマンドとして正式にされました。
Feather Standards Track [Page 122] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[122ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
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 RFC2980のXOVERコマンドは新しいOVER(セクション8.3)とLIST OVERVIEW.FMT(セクション8.4)コマンドとして正式にされました。 範囲に関してまた、メッセージイドに前者を適用できます。
o The concept of article metadata (Section 8.1) has been formalised,
allowing the Bytes and Lines pseudo-headers to be deprecated.
o Bytesと線疑似ヘッダーが推奨しないのを許容して、記事メタデータ(セクション8.1)の概念は正式にされました。
Client authors should note in particular that lack of support for the CAPABILITIES command is a good indication that the server does not support this specification.
クライアント作者は、CAPABILITIESコマンドのサポートの不足がサーバがこの仕様をサポートしないという良い指示であることに特に注意するべきです。
Feather Standards Track [Page 123] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[123ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Author's Address
作者のアドレス
Clive D.W. Feather THUS plc 322 Regents Park Road London N3 2QQ United Kingdom
クライヴD.W.Feather THUS plc322Regents Park RoadロンドンN3 2QQイギリス
Phone: +44 20 8495 6138 Fax: +44 870 051 9937 EMail: clive@demon.net URI: http://www.davros.org/
以下に電話をしてください。 +44 20 8495 6138、Fax: +44 9937年の870 051メール: clive@demon.net ユリ: http://www.davros.org/
Feather Standards Track [Page 124] RFC 3977 Network News Transfer Protocol (NNTP) October 2006
羽の標準化過程[124ページ]RFC3977ネットワークの電子情報を転送するプロトコル(NNTP)2006年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Feather Standards Track [Page 125]
羽の標準化過程[125ページ]
一覧
スポンサーリンク
