RFC4707 日本語訳
4707 Netnews Administration System (NAS). P. Grau, V. Heinau, H.Schlichting, R. Schuettler. October 2006. (Format: TXT=86510 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Grau
Request for Comments: 4707 V. Heinau
Category: Experimental H. Schlichting
R. Schuettler
Freie Universitaet Berlin
October 2006
コメントを求めるワーキンググループP.グラウの要求をネットワークでつないでください: 4707年のV.Heinauカテゴリ: 実験的なH.のSchlichting R.シュトラーFreie Universitaetベルリン2006年10月
Netnews Administration System (NAS)
ネットニュース行政システム(NAS)
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFはどんな目的、および発行するという決定が配布しているプロトコルとのセキュリティのようなもの、輻輳制御または不適当な相互作用のためのIETFレビューに基づいていないという特定のメモでもこのRFCのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実装と展開のために値を評価する際に警戒するべきです。
Abstract
要約
The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol.
Netnews政権System(NAS)はインターネットでネットニュース(また、Netnewsとして、知られている)の管理と使用法を簡素化するフレームワークです。 ニュースグループと階層構造の管理のためのデータは、分配された階層型データベースで保たれて、クライアント/サーバプロトコルを通して利用可能です。
The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually. News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user.
データベースはニュースサーバ、ニュース管理者、およびニュース読者はアクセス可能です。 ニュースサーバは自動的にそれらの構成をアップデートできます。 管理者は手動でデータを得ることができます。 ニュース読者プログラムは自動的かユーザの裁量におけるNASサーバからユーザまである情報を得ることができます。裁量はグループと階層構造の詳細な情報を提供します。
Grau, et al. Experimental [Page 1] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[1ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible. Furthermore, NAS is able to reflect the somewhat chaotic structure of Usenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS- compliant software.
NASはコントロールメッセージの現在の、そして、確立したプロセスとの共存で使用可能です。 求められていない干渉は不可能です。 その上、NASはUsenetのいくらか混沌の構造を階層型データベースに反映できます。 既存のニュースリレー、ニュースサーバ、またはニュース読者ソフトウェアの変更なしでNASを使用できます。 しかしながら、NAS対応することのソフトウェアでいくつかのタスクを達成するほうがよいでしょう。
Table of Contents
目次
1. Introduction ....................................................3
2. Overview ........................................................4
3. Protocol Level ..................................................5
4. Description of Functions ........................................6
5. Definitions .....................................................7
6. Specification of the NAS Protocol (TCP) .........................8
6.1. Responses ..................................................8
6.1.1. Overview ............................................8
6.1.2. Response Code Values, Structure, and Meaning ........8
6.2. Connection Setup ...........................................9
6.3. Commands ..................................................10
6.3.1. Structure ..........................................10
6.3.2. Overview ...........................................10
6.3.3. Detailed Description ...............................10
6.3.3.1. HELP ......................................11
6.3.3.2. INFO ......................................12
6.3.3.3. DATE ......................................13
6.3.3.4. VERS ......................................14
6.3.3.5. QUIT ......................................15
6.3.3.6. LIST ......................................16
6.3.3.7. LSTR ......................................18
6.3.3.8. HIER ......................................19
6.3.3.9. DATA ......................................21
6.3.3.10. GETP .....................................22
6.3.3.11. GETA .....................................25
6.3.3.12. Unknown Commands and Syntax Errors .......27
6.3.4. Data Headers .......................................27
6.4. Status Indicators .........................................41
6.5. Newsgroup Types ...........................................41
6.6. Hierarchy Types ...........................................42
6.7. PGP Keys ..................................................42
7. Specification of the NAS Protocol (UDP) ........................44
8. IANA Considerations ............................................44
9. Security Considerations ........................................44
10. Response Codes (Overview) .....................................45
11. Data Headers for DATA and HIER Commands (Overview) ............45
1. 序論…3 2. 概要…4 3. レベルについて議定書の中で述べてください…5 4. 機能の記述…6 5. 定義…7 6. NASプロトコル(TCP)の仕様…8 6.1. 応答…8 6.1.1. 概要…8 6.1.2. 応答コード値、構造、および意味…8 6.2. 接続セットアップ…9 6.3. コマンド…10 6.3.1. 構造…10 6.3.2. 概要…10 6.3.3. 詳細な記述…10 6.3.3.1. ヘルプ…11 6.3.3.2. インフォメーション…12 6.3.3.3. デートしてください…13 6.3.3.4. VERS…14 6.3.3.5. やめてください…15 6.3.3.6. 記載してください…16 6.3.3.7. LSTR…18 6.3.3.8. HIER…19 6.3.3.9. データ…21 6.3.3.10. GETP…22 6.3.3.11. 下駄…25 6.3.3.12. 未知のコマンドと構文エラー…27 6.3.4. データヘッダー…27 6.4. 状態インディケータ…41 6.5. ニュースグループはタイプされます…41 6.6. 階層構造タイプ…42 6.7. PGPキー…42 7. NASプロトコル(UDP)の仕様…44 8. IANA問題…44 9. セキュリティ問題…44 10. 応答は(概要)をコード化します…45 11. データのデータのためのヘッダーとHIERは(概要)を命令します…45
Grau, et al. Experimental [Page 2] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[2ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
12. References ....................................................46
12.1. Normative References .....................................46
12.2. Informative References ...................................47
12. 参照…46 12.1. 標準の参照…46 12.2. 有益な参照…47
1. Introduction
1. 序論
An increasing number of newsgroups, hierarchies, and articles has made the administration of news servers a complex and time-consuming task. The tools for the administration have remained unchanged for ten years and are no longer appropriate. Many hierarchies are inconsistent; many new newsgroups are not created or only with a large delay; removed groups keep lurking in the configuration files for a long period of time. There is no administration tool that utilizes the power of the Internet, and it is not possible to check the consistency of the news server at a given point of time.
増加する数のニュースグループ、階層構造、および記事がニュースサーバの管理を複雑で手間がかかったタスクにしました。 管理のためのツールは、10年間変わりがなくて、またもう適切ではありません。 多くの階層構造が矛盾しています。 多くの新しいニュースグループは、作成もされませんし、単に大きい遅れでそうもしません。 取り除かれたグループは長い年月の間構成ファイルに潜み続けます。 インターネットのパワーを利用する管理ツールが全くありません、そして、時間の与えられたポイントでニュースサーバの一貫性をチェックするのは可能ではありません。
Users find it difficult to get an overview of the newsgroups, the charter of a particular one, which language is preferred, or whether a group is moderated. Renaming, the status change from moderated to unmoderated or vice versa, and the splitting of a group into several others are dynamic processes. These processes are in common use, but it takes a long time until every news server is aware of these changes.
ユーザが、ニュースグループの概要、特定のものの特許を得るのが難しいのがわかって、その言語が好ましく、グループが加減されるかどうかをそうされます。 改名、状態が加減されるのから非加減されるのに変化するか、逆もまた同様です、数人の他のものへのグループの分かれるのはダイナミックなプロセスです。 これらのプロセスは共用ですが、あらゆるニュースサーバがこれらの変化を意識するまで、それは長くかかっています。
An increasing number of faked control messages has appeared in the last few years. Purposely or accidentally, control messages were sent to foreign news servers to create or remove a certain group, although this was not approved according to the rules of the hierarchy in question. Due to this fact, automatic creation and removal are disabled on many news servers, and several dead groups have not been deleted. It is very difficult for users to determine the current status of a group, and in some cases they simply cannot tell that the group they are posting to is not an active group but a dead or invalid one.
増加する数の見せかけられたコントロールメッセージがここ数年間で現れました。 わざわざか偶然、あるグループを創設するか、または取り除くためにコントロールメッセージを海外ニュースサーバに送りました、問題の階層構造の規則に従って、これは承認されませんでしたが。 この事実のため、自動作成と取り外しは多くのニュースサーバで無効にされます、そして、いくつかの死んでいるグループは削除されていません。 ユーザがグループの現在の状態を決定するのが、非常に難しく、いくつかの場合、彼らがそれを絶対に言うことができない、彼らが掲示しているグループ、活動的なグループではなく、死んでいるか無効のものがそうです。
It is the design goal of Netnews Administration System (NAS) to provide an out-of-band system that helps to maintain, propagate, and deliver the required information. There will not be any interference with current protocols and standards. It is not intended to make use of control messages or some special Network News Transfer Protocol (NNTP) commands. The advantage of NAS is that it provides more information in a more structured format than that of control messages. Not only news server administrators but also Usenet users can get more detailed information about newsgroups and hierarchies.
それは必須情報を維持して、伝播して、提供するのを助けるバンド系のアウトを提供するNetnews政権System(NAS)のデザイン目標です。 現在のプロトコルと規格の少しの干渉もないでしょう。 それがコントロールメッセージかいくつかの特別なネットワークの電子情報を転送するプロトコル(NNTP)コマンドを利用することを意図しません。 NASの利点はコントロールメッセージのものより構造化された形式に詳しい情報を提供するということです。 ニュースサーバアドミニストレータだけではなく、Usenetユーザもニュースグループと階層構造の、より詳細な情報を得ることができます。
Due to the fact that a client connects to a server and the server asks for authentication, this is a more reasonable procedure for transmitting information than that for control messages.
クライアントがサーバに接続して、サーバが認証を求めるという事実のために、これは、情報を伝えるためのコントロールメッセージのためのそれより妥当な手順です。
Grau, et al. Experimental [Page 3] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[3ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Furthermore, it is possible to check for changes on a regular basis at customized intervals to keep local data up-to-date.
その上、ローカルのデータを最新に保つために変化がないかどうか定期的にカスタム設計された間隔で、チェックするのは可能です。
2. Overview
2. 概要
NAS is based on a database that contains information about certain groups and hierarchies. This database is structured in a hierarchical manner and distributed to various servers, and it is able to receive queries at any time. The service is comparable to directory services like DNS, Lightweight Directory Access Protocol (LDAP), or Network Information Service (NIS). The NAS protocol is inspired by protocols like NNTP and SMTP. The port 991 is reserved for NAS and registered by the Internet Assigned Numbers Authority (IANA) [IANA-PN].
NASはあるグループと階層構造の情報を含むデータベースに基づいています。 このデータベースは、階層的な方法で構造化されて、様々なサーバに分配されます、そして、それはいつでも、質問を受けることができます。 サービスはDNS、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)、またはNetwork情報Service(NIS)のようなディレクトリサービスに匹敵しています。 NASプロトコルはNNTPとSMTPのようなプロトコルによって奮い立たせられます。 ポート991は、NASのために予約されて、インターネットAssigned民数記Authority(IANA)[IANA-PN]によって登録されます。
The organizational structure of NAS is hierarchical; this means that a NAS root server collects data from the sub-servers that are authoritative for certain hierarchies. The root server signs the data and distributes it authoritatively. Replication of database entries is possible. The hierarchical structure can consist of multiple levels. Usage of the database is possible for news servers, news readers, and special client programs. The communication is based on TCP and UDP.
NASの組織体制は階層的です。 これは、NASルートサーバーが、ある階層構造に、正式のサブサーバからデータを集めることを意味します。 ルートサーバーは、厳然とデータに署名して、それを分配します。 データベースエントリーの模写は可能です。 階層構造は複数のレベルから成ることができます。 ニュースサーバ、ニュース読者、および特別なクライアントプログラムに、データベースの用法は可能です。コミュニケーションはTCPとUDPに基づいています。
Taking the real world into account, there might be some policy problems with a single root server. But it is possible to establish a structure like that of the current Usenet system, where some hierarchies have a good administration with a well-defined system of rules, and where some are not well maintained. The goal is to get as much information as possible under one hat, but there can be no "official" force to achieve this.
本当の世界を考慮に入れて、ただ一つのルートサーバーに関するいくつかの方針問題があるかもしれません。しかし、現在のUsenetシステムのもののような構造を確立するのは可能です。そこでは、いくつかの階層構造には規則の明確なシステムがある良い管理があって、或るものはよく維持されません。 目標はできるだけ「公式」の力が全くあるはずがないのを多くの情報にこれを実現させることです。
During the startup phase, it is quite likely that there will be a root server, handling just hierarchies with strict rules and accepted authorities (e.g., BIG8, de.*, us.*, bln.*, fr.*, it.*).
始動段階の間、ルートサーバーがかなりありそうでしょう、厳しい規則と認められた権威者でまさしく階層構造を扱って。(例えば、BIG8(de)、*、私たち. 十億. *、*が. *をfrして、それが*である、)
However, it is also imaginable to have some NAS servers providing data on, for example, alt.!binaries, some providing data on alt.*, and even some providing alt.* following special policies or sets of rules.
しかしながら、また、alt例えば、2種混合毒ガス(altに関するいくつかの提供データ)に関するデータに*を提供して、alt*次の個別保険証券かセットの規則をいくつかの提供にさえ提供するいくつかのNASサーバを持っているのも想像可能です。
An administrator using NAS will have the choice to use just one root server (and all its data) or to use another NAS server for special hierarchies.
NASを使用している管理者はちょうど1つのルートサーバー(そして、すべてのデータ)を使用するか、または特別な階層構造に別のNASサーバを使用する選択を持つでしょう。
Grau, et al. Experimental [Page 4] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[4ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
.............. .............. ...................
. NAS server. . NAS server. . NAS server .
. . . . . alt.*, .
. alt.* . . Big8 . . !alt.binaries.*.
.............. .............. ...................
. database . . database . . database .
.............. .............. ...................
^ ^ ^ ^
`--+ +--' `------+ +----'
| | | |
.------------. .------------.
| NAS client | | NAS client |
+------------+ +------------+
| netnews | | netnews |
| server | | server |
.------------. .------------.
.............. .............. ................... . NASサーバNASサーバNASサーバ… alt*、alt*Big8alt.binaries*。 .............. ................... . データベースデータベースデータベース。 .............. ................... ^ ^ ^ ^ `--+ +--' `------+ +----' | | | | .------------. .------------. | NASクライアント| | NASクライアント| +------------+ +------------+ | ネットニュース| | ネットニュース| | サーバ| | サーバ| .------------. .------------.
Configuration A Configuration B
構成は構成Bです。
Figure 1
図1
NAS contains information about newsgroups and complete hierarchies. Furthermore, it contains information about the hierarchies' inheritable entries and default values for a single newsgroup.
NASはニュースグループと完全な階層構造の情報を含んでいます。 その上、それは単一のニュースグループのための階層構造の相続可能なエントリーとデフォルト値の情報を含んでいます。
3. Protocol Level
3. プロトコルレベル
It is expected that the real-life use of NAS will change the requirements for the Netnews Administration System. On the one hand, the protocol has to be extensible and flexible in order to implement improvements; on the other hand, it must ensure compatibility between different versions. A simultaneous migration of all sites using NAS to a new protocol version is not likely to happen. To solve this problem, NAS has a protocol level. This protocol level describes the current functionality. The protocol level, being a number between 1 and 32767, is negotiated at connection setup. Enhancements and modifications must use a different protocol level than that of their predecessors. (Usually the protocol level is incremented by 1 with every new version of the protocol specification.) Every current or future implementation MUST be compatible with protocol level 1 in order to fall back to this level if communication on a higher level fails.
NASの現実の使用がNetnews政権Systemのための要件を変えると予想されます。 一方では、プロトコルは、改良を実装するために広げることができてフレキシブルでなければなりません。 他方では、それは異なった見解の間の互換性を確実にしなければなりません。 新しいプロトコルバージョンにNASを使用するすべてのサイトの同時の移行は起こりそうにはありません。 この問題を解決するために、NASには、プロトコルレベルがあります。 このプロトコルレベルは現在の機能性について説明します。 1〜32767の数でありプロトコルレベルは接続設定で交渉されます。 増進と変更は彼らの前任者のものと異なったプロトコルレベルを使用しなければなりません。 (通常、プロトコルレベルはプロトコル仕様のあらゆる新しいバージョンで1つ増加されます。) あらゆる現在の、または、将来の実装が、より高いレベルに関するコミュニケーションが失敗するならこのレベルへ後ろへ下がるためにプロトコルレベル1と互換性がなければなりません。
An implementation of higher protocol levels should be able to emulate the behavior of lower levels, even if this implies a loss of features. The negotiation of the protocol level between client and server is described in the specification of the command VERS. If there is no agreement on the protocol level, only commands of the
より高いプロトコルレベルの実装は下のレベルの振舞いを見習うことができるべきです、これが特徴の損失を含意しても。 クライアントとサーバの間のプロトコルレベルの交渉はコマンドVERSの仕様で説明されます。 プロトコルレベルの協定ではなく、コマンドしかありません。
Grau, et al. Experimental [Page 5] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[5ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
protocol level 1 MUST be used. Documents enhancing or modifying the NAS standard MUST specify on which level these changes take place and how the behavior should be in other protocol levels.
プロトコルレベル1を使用しなければなりません。 NAS規格を高めるか、または変更するドキュメントはこれらの変化がどのレベルで起こるか、そして、振舞いが他のプロトコルレベルにどのようにあるべきであるかを指定しなければなりません。
This document describes protocol level 1.
このドキュメントはプロトコルレベル1について説明します。
4. Description of Functions
4. 機能の記述
In order to use an NAS server, a connection must be opened by the client. The NAS server can be located in the same domain or somewhere else on the Internet.
NASサーバを使用するために、クライアントは接続を開かなければなりません。 NASサーバは同じドメインかインターネットの他のどこかに位置できます。
The NAS system is hierarchical. The idea is to have an NAS root server like the DNS root servers. The root server distributes the data collected from client NAS servers that are authoritative servers for their hierarchy. The maintenance of the authoritative data is possible on any system. The root server collects the data and makes them available to other servers, which can in turn distribute these data to other servers. The administrator has the opportunity to make use of either all data or only parts of the database. NAS servers can ask multiple NAS servers for data. An attached time stamp makes it possible to distinguish between new and old data and to avoid loops in the propagation.
NASシステムは階層的です。 考えはDNSがサーバを根づかせるようにNASルートサーバーを持つことです。 ルートサーバーはそれらの階層構造のために正式のサーバであるクライアントNASサーバから集められたデータを分配します。 信頼すべきデータのメインテナンスはどんなシステムの上でも可能です。 ルートサーバーは、データを集めて、それらは他のサーバに利用可能になります。(順番に、サーバは他のサーバにこれらのデータを分配できます)。 管理者には、データベースのすべてのデータか部分のどちらかだけを利用する機会があります。 NASサーバは複数のNASサーバにデータを求めることができます。 付属タイムスタンプで、新しくて古いデータを見分けて、伝播で輪を避けるのは可能になります。
To describe the NAS in greater detail, it is necessary to emphasize the hierarchical design of the NAS system. The following figure shows the propagation of data along the server hierarchy.
詳細によりすばらしいNASについて説明するために、NASシステムの階層化設計を強調するのが必要です。 以下の図はサーバ階層構造に沿ってデータの伝播を示しています。
Authoritative data for a newsgroup or a hierarchy are collected and written into a database. These data are available through a local NAS server and are collected from this authoritative server by upstream NAS servers.
ニュースグループか階層構造のための信頼すべきデータは、データベースに集められて、書かれています。 これらのデータは、ローカルのNASサーバを通して利用可能であり、上流のNASサーバによってこの正式のサーバから集められます。
There may also be NAS servers that are not authoritative servers; these servers merely provide the information they collect from other NAS servers to clients such as news servers, administration programs, and news readers.
また、正式のサーバでないNASサーバがあるかもしれません。 これらのサーバは単に、それらが他のNASサーバからニュースサーバや、運用管理プログラムや、ニュース読者などのクライアントに集める情報を提供します。
Grau, et al. Experimental [Page 6] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[6ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
............ collects from >
. root NAS.-------------------------+
. server .----------------+ |
............ | |
. database. | |
............ | |
^ v | ..........................
| | | . NAS server .
| |distributes | . authoritative for de.*.
queries| | | ..........................
| | | . database .
^ v | ..........................
.............. |
. NAS server. `--------+
.............. |
. database . ...........................
.............. . NAS server .
^ ^ ^ . authoritative for bln.*.
| | | .---------. ...........................
q | | `--| netnews | . database .
u | | | server | ...........................
e | | .---------.
r | |
i | | .---------.
e | `--| admin |
s | | program |
| .---------.
|
| .---------.
`--| news |
| reader |
.---------.
…… ……は>を取ります。NASを根づかせてください。-------------------------+ . サーバ。----------------+ | ............ | | . データベース。 | | ............ | | ^v| .......................... | | | . NASサーバ。| |分配します。| . de*質問において、正式です。| | | .......................... | | | . データベース^v| .......................... .............. | . NAS'サーバ‘--------+ .............. | . データベース。 .............. . NASサーバ^ ^ ^十億*において、正式です。| | | .---------. …… q| | `--| ネットニュース| . データベースu| | | サーバ| …… e| | .---------. r| | i| | .---------. e| `--| アドミン| s| | プログラム| | .---------. | | .---------. `--| ニュース| | 読者| .---------.
Figure 2
図2
Requests to an NAS server originating at a client (as well as at another server) are accomplished in several steps: establishing a connection, authentication (optional), negotiating a protocol level (optional), queries on the database, and termination.
クライアント(別のサーバと同じくらいよく)で起因するNASサーバへの要求は以下の数ステップで実行されます: 接続、認証(任意の)、プロトコルレベル(任意の)、データベースにおける質問を交渉して、および終了を確立します。
5. Definitions
5. 定義
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Grau, et al. Experimental [Page 7] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[7ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
6. Specification of the NAS Protocol (TCP)
6. NASプロトコルの仕様(TCP)
6.1. Responses
6.1. 応答
6.1.1. Overview
6.1.1. 概要
An answer starts with a response code (a three-digit number),
optionally followed by white space and a textual message. Then the
actual text/data follows. Text is sent as a series of successive
lines of textual matter, each terminated with CRLF. A single line
containing only a single period ('.') is sent to indicate the end of
the text (i.e., the server will send a CRLF at the end of the last
line of text, a period, and another CRLF).
答えは余白が任意にあとに続いた応答コード(3桁数)と原文のメッセージから始まります。 そして、実際のテキスト/データは従います。 原文の件の一連の連続した系列、CRLFと共に終えられたそれぞれとしてテキストを送ります。 ただ一つの期間だけを含む単線、('、'、)、テキスト(すなわち、サーバはテキストの最終ライン、期間、および別のCRLFの端にCRLFを送る)の終わりを示すために、送ります。
Answer = response-code [answertext] CRLF
text CRLF
"." CRLF
「=応答コード[answertext]CRLFテキストCRLFに答えてください」、」 CRLF
If the original text contains a period as the first character of the text line, that first period is doubled. Therefore, the client must examine the first character of each line received and, for those beginning with a period, determine either that this is the end of the text or that it should collapse the doubled period to a single one.
原本がテキスト系列の最初のキャラクタとして期間を含んでいるなら、その初潮は倍にされます。 期間があるそれらの始めの間、したがって、クライアントは、受け取られたそれぞれの台詞の最初のキャラクタを調べて、これがテキストの終わりであるかただ一つのものまで倍増している期間を潰すべきであると決心しなければなりません。
Example
例
<-- INFO
--> 101 Information follows
Server: nas.example.org (192.0.2.100)
Uptime: 2 weeks, 3 days, 5 hours, 9 minutes
Software: NAS 1.0
Client: client.example.org (192.0.2.123)
Connection: 9 minutes
Highest protocol level supported: 1
Requested protocol level: 1
Protocol level used: 1
.
<--INFO-->101情報はServerに続きます: nas.example.org、(192.0 .2 .100) 動作可能時間: 2週間、3日間、5時間、9分のSoftware: NAS1.0クライアント: client.example.org、(192.0 .2 .123)接続: Highestプロトコルレベルがサポートした9分: 1はプロトコルレベルを要求しました: 1 レベルが使用したプロトコル: 1 .
6.1.2. Response Code Values, Structure, and Meaning
6.1.2. 応答コード値、構造、および意味
The first digit of the response code indicates the message type (i.e., information, success, warning, error, or data):
応答コードの最初のケタはメッセージタイプ(すなわち、情報、成功、警告、誤り、またはデータ)を示します:
1xx Information 2xx Request successful 3xx Request successful, data follow 4xx Request accepted, but no operation possible
1xxの情報の2xx Requestのうまくいっている3xx Requestうまくいって、受け入れられた4xx Requestに続きますが、データは可能などんな操作も続きません。
Grau, et al. Experimental [Page 8] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[8ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
5xx Request is wrong (syntax error), is not implemented, or leads to
an internal error
6xx Request successful, data follow until end mark
5xx Requestは6xx Requestうまくいった状態で間違った(構文エラー)である、実装されないか、または内部エラーに通じます、とデータはエンド・マークまで続きます。
The second digit specifies the message category:
2番目のケタはメッセージカテゴリを指定します:
x0x Connection-related stuff x1x Queries, answers, or data x2x Server-server communication x3x Authentication, authorization x8x Non-standard extensions x9x Debugging output
x0xの接続関連のもののx1x Queries、答え、またはデータx2x Server-サーバコミュニケーションx3x Authentication、承認のx8x Non標準の拡大x9x Debugging出力
The actual response code for a specific command is listed in the description of the commands. Answers of the type 1xx, 2xx, 4xx, and 5xx can have a text after the numerical code. 3xx answers contain one or more parameters with data; the exact format is explained in the description of the commands.
特定のコマンドのための実際の応答コードはコマンドの記述で記載されています。 タイプ1xx、2xx、4xx、および5xxの答えは数字コードの後にテキストを持つことができます。 3xx答えはデータがある1つ以上のパラメタを含んでいます。 正確な書式はコマンドの記述で説明されます。
An answer to an incorrect request may be longer than one line.
不正確な要求の答えは1つの系列より長いかもしれません。
6.2. Connection Setup
6.2. 接続設定
NAS typically uses port 991, which is reserved by IANA [IANA-PN]. If a connection is set up by the client, the server answers immediately (without a request) with the greeting message, which will start with code 200:
NASはポート991を通常使用します。(それは、IANA[IANA-PN]によって予約されます)。 サーバは、すぐに(要求なしで)、あいさつメッセージで接続がクライアントによってセットアップされるとどれがコード200から始まるかと答えます:
--> 200 Welcome!
nas.example.org ready
.
-->200は準備ができていた状態でnas.example.orgを歓迎します。
If a connection is refused because the client has no permission to access the server, the answer code is 434. That decision can be made on connection startup based on the client's IP address. When the server is currently out of service, the answer code is 404.
クライアントにはサーバにアクセスする許可が全くないので接続が拒否されるなら、答えコードは434です。 クライアントのIPアドレスに基づく接続始動でその決定をすることができます。 サーバが現在使われなくなっているとき、答えコードは404です。
Examples:
例:
--> 434 You have no permission to retrieve data. Good bye.
.
--あなたが許可を全く持っていない>434はデータを検索します。 さようなら。 .
--> 404 Maintenance time
.
-->404メインテナンス時間。
After sending a 404 or 434 message, the connection will be closed.
404か434メッセージを送った後に、接続は閉店するでしょう。
Grau, et al. Experimental [Page 9] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[9ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
6.3. Commands
6.3. コマンド
6.3.1. Structure
6.3.1. 構造
A command consists of a command word, sometimes followed by a parameter. Parameters are separated from the command word by white space.
コマンドはパラメタが時々あとに続いたコマンド単語から成ります。 パラメタは余白によってコマンド単語と切り離されます。
Commands used in the NAS protocol are not case sensitive. A command word or parameter may be uppercase, lowercase, or any mixture of upper- and lowercase.
NASプロトコルに使用されるコマンドは大文字と小文字を区別していません。 コマンド単語かパラメタが、大文字して、小文字であって上側と小文字のどんな混合物であるかもしれません。
The length of a command line is not limited. If the need to limit the length of command lines in real-life implementations arises, answer code 513 (line too long) should be returned.
コマンドラインの長さは限られていません。 現実の実装における、コマンドラインの長さを制限する必要性が起こるなら、答えコード513(あまりに長い間、立ち並んでいます)は返されるべきです。
The protocol level described in this document uses command words with a length of exactly four characters each.
本書では説明されたプロトコルレベルはまさにそれぞれ4つのキャラクタの長さがあるコマンド単語を使用します。
In examples, octets sent to the NAS server are preceded by "<-- " and those sent by the NAS server by "--> ". The indicator is omitted if the direction of the dialog does not change.
例では、NASサーバに送られた八重奏で先行されている、「<、--、」 ものがNASサーバで発信した「--、>、」 対話の方向が変化しないなら、インディケータは省略されます。
6.3.2. Overview
6.3.2. 概要
The commands described below are defined using the Augmented Backus- Naur Form (ABNF) defined in [RFC4234]. The definitions for 'ALPHA', 'CRLF', 'DIGIT', 'WSP' and 'VCHAR' are taken from appendix B of [RFC4234] and not repeated here.
以下で説明されたコマンドは、ナウアForm(ABNF)が[RFC4234]で定義したAugmentedバッカスを使用することで定義されます。 'アルファー'、'CRLF'、'DIGIT'、'WSP'、および'VCHAR'のための定義は、[RFC4234]の付録Bから取られて、ここで繰り返されません。
The following ABNF definitions constitute the set of NAS commands that can be sent from the client to an NAS server.
以下のABNF定義はクライアントからNASサーバに送ることができるNASコマンドのセットを構成します。
6.3.3. Detailed Description
6.3.3. 詳述
Some overall definitions follow:
いくつかの総合的な定義が続きます:
text = %d1-9 / ; all octets except
%d11-12 / ; US-ASCII NUL, CR and LF
%d14-255
テキスト=%d1-9/。 %d11-12/以外のすべての八重奏。 米国-ASCIIのNUL、CR、およびLF%d14-255
answertext = WSP *( ALPHA / DIGIT / "+" / "-" / "/" / "_" /
"." / "," / ":" / "=" / "?" / "!" / SP )
answertextはWSP*と等しいです。「(アルファ/ケタ/「+ 」 /「-」/」 /」 /"_"/」、」 /、」、」 : 」 」 //「=」/“?"/“!"/SP、)
utc-time = 14DIGIT ; the date and time of the server in UTC
; YYYYMMDDhhmmss
utc-時間は14DIGITと等しいです。 UTCのサーバの日時。 YYYYMMDDhhmmss
response-code = 3DIGIT ; three digit number
応答コードは3DIGITと等しいです。 3桁数
Grau, et al. Experimental [Page 10] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[10ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Newsgroup names and hierarchy names are defined according to the following ABNF definitions. Since a hierarchy name can be the same as a newsgroup name (e.g., hierarchy bln.announce.fub.* and newsgroup name bln.announce.fub), there is no difference between the two.
ニュースグループ以下のABNF定義に従って、名前と階層構造名は定義されます。 階層構造名がニュースグループ名(例えば、階層構造のbln.announce.fub*とニュースグループ名のbln.announce.fub)と同じである場合があるので、2つの間には、違いが全くありません。
name = plain-component *("." component)
component = plain-component / encoded-word
encoded-word = 1*( lowercase / DIGIT /
"+" / "-" / "/" / "_" / "=" / "?" )
plain-component = component-start *component-rest
component-start = lowercase / DIGIT
lowercase = %x61-7A ; letter a-z lowercase
component-rest = component-start / "+" / "-" / "_"
「小文字の/ケタ小文字の=コンポーネントのスタート*コンポーネント休息コンポーネント1つの*(」 /ケタ/「+」/「-」/」 //"_"/「=」/“?"を小文字で印刷する)明瞭なコード化された明瞭なコンポーネント/単語のコード化されたWord=コンポーネント=始め=%x61-7Aと=明瞭なコンポーネント*(「.」 コンポーネント)コンポーネント=を命名してください。 手紙の1zの小文字のコンポーネント休息はコンポーネント始め/「+」/「-」/"_"と等しいです。
NOTE: This definition of newsgroup name is in reference to "News Article Format and Transmission" [SON1036]. When the document "News Article Format" [USEFOR] is established as an RFC, its definitions should be integrated into a higher protocol level of NAS.
以下に注意してください。 ニュースグループ名のこの定義は「ニュース記事形式とトランスミッション」[SON1036]に関しています。 「ニュース記事形式」[USEFOR]というドキュメントがRFCと書き立てられるとき、定義はNASの、より高いプロトコルレベルと統合されるべきです。
6.3.3.1. HELP
6.3.3.1. ヘルプ
Description
記述
This command prints a short help text on a given command. If called without parameters, it will display a complete list of commands.
このコマンドは与えられたコマンドに関する短い助けテキストを印刷します。 パラメタなしで呼ばれると、それはコマンドに関する全リストを表示するでしょう。
help-cmd = "HELP" [WSP commandname] CRLF
助け-cmdは「助け」[WSP commandname]CRLFと等しいです。
commandname = "DATA" / "DATE" / "GETP" / "GETA" /
"HELP" / "HIER" / "INFO" / "LIST" /
"LSTR" / "QUIT" / "VERS"
commandnameは「データ」/「日付」/"GETP"/「下駄」/「助け」/"HIER"/「インフォメーション」/「リスト」/"LSTR"/「辞任」/「VERS」と等しいです。
Possible answers
可能な答え
100: Command overview, command description 410: Indicates that the server is not giving any information
100: 概観、コマンド記述410を命令してください: サーバが少しの情報も教えていないのを示します。
help-answer = "410" [answertext] CRLF
text CRLF
"." CRLF
help-answer =/ "100" [answertext] CRLF
text CRLF
"." CRLF
「助け答え=「410[answertext]インチCRLFテキストCRLF」。」 「CRLF助け答え=/「100インチ[answertext]CRLFテキストCRLF」。」 CRLF
Examples
例
<-- HELP
<--ヘルプ
Grau, et al. Experimental [Page 11] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[11ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
--> 100 NAS server nas.example.org - Version 1.0
-->100NASサーバnas.example.org--バージョン1.0
Supported commands:
DATA - data for a newsgroup
DATE - show time of server in UTC
GETP - get package
GETA - get data from an authoritative server
HELP - show this help
HIER - data for a hierarchy
INFO - show info on current connection
LIST - list newsgroups or hierarchies
LSTR - recursive list newsgroups or hierarchies
QUIT - close the connection
VERS - show or set current protocol level
支持されたコマンド: DATE(UTC GETPのサーバのショー時間)が得るニュースグループのためのデータがGETAをパッケージするというDATAはサーバヘルプから正式のデータを得ます--この助けHIERを見せてください--INFO--現在の接続LISTに関するショーインフォメーション--再帰的なリストニュースグループか階層構造QUIT--接続VERSを閉じるというリストニュースグループか階層構造LSTRが示している階層構造かセット電流のためのデータはレベルについて議定書の中で述べます。
Contact address nas@example.org
.
アドレス nas@example.org に連絡してください。
<-- HELP LIST
--> 100 LIST
LIST - list newsgroups or hierarchies
Syntax: LIST hierarchy ...
Get a list of newsgroups and sub-hierarchies
directly under the parameter hierarchy
.
<--HELP LIST(>100LIST LIST)はニュースグループか階層構造Syntaxを記載します: LIST階層構造… パラメタ階層構造の直接下でニュースグループとサブ階層構造のリストを手に入れてください。
<-- HELP NOOP
--> 410
unknown command "NOOP"
.
<--ヘルプNOOP--未知の>410は"NOOP"を命令します。
6.3.3.2. INFO
6.3.3.2. インフォメーション
Description
記述
Prints information about the current connection, the server, and the client.
現在の接続、サーバ、およびクライアントの情報を印刷します。
info-cmd = "INFO" CRLF
インフォメーション-cmdは「インフォメーション」CRLFと等しいです。
Possible answers
可能な答え
101: Normal answer; prints some information about client
and server
101: 通常の答え。 クライアントとサーバの何らかの情報を印刷します。
400: Indicates that the server is not giving any information
400: サーバが少しの情報も教えていないのを示します。
Grau, et al. Experimental [Page 12] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[12ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
info-answer = "400" [answertext] CRLF
text CRLF
"." CRLF
info-answer =/ "101" [answertext] CRLF
text CRLF
"." CRLF
「インフォメーション答え=「400[answertext]インチCRLFテキストCRLF」。」 「CRLFインフォメーション答え=/「101インチ[answertext]CRLFテキストCRLF」。」 CRLF
Examples
例
<-- INFO
--> 101 Information follows
Server: nas.example.org (192.0.2.100)
Uptime: 2 weeks, 3 days, 5 hours, 9 minutes
Software: NAS 1.0
Client: client.example.org (192.0.2.123)
Connection: 9 minutes
Highest protocol level supported: 1
Requested protocol level: 1
Protocol level used: 1
<--INFO-->101情報はServerに続きます: nas.example.org、(192.0 .2 .100) 動作可能時間: 2週間、3日間、5時間、9分のSoftware: NAS1.0クライアント: client.example.org、(192.0 .2 .123)接続: Highestプロトコルレベルが支持した9分: 1はプロトコルレベルを要求しました: 1 レベルが使用したプロトコル: 1
End
.
終わってください。
<-- INFO
--> 400
No information available.
.
<--INFO--利用可能な>400いいえ情報。 .
6.3.3.3. DATE
6.3.3.3. 日付
Description
記述
Prints the current time of the server in UTC (Universal Coordinated Time) in the format YYYYMMDDhhmmss, followed by an optional comment. The DATE command is only for informational use and to check the server time. For regular transmission of time over the network, the Network Time Protocol (NTP) [RFC1305] should be used.
任意のコメントがあとに続いた形式YYYYMMDDhhmmssでUTC(普遍的なCoordinated Time)のサーバの現在の時間を印刷します。 DATEコマンドは、情報の使用だけ、サーバ時間をチェックすることです。 タイム・オーバーの正透過のために、ネットワーク、Network Timeプロトコル(NTP)[RFC1305]は使用されるべきです。
date-cmd = "DATE" CRLF
日付-cmdは「日付」CRLFと等しいです。
Possible answers
可能な答え
300: Print the UTC time in specified format; see below 511: Error; print an error message
300: 指定された形式でUTC時間を印刷してください。 511未満を見てください: 誤り。 エラーメッセージを印刷してください。
date-answer = "511" [answertext] CRLF
text CRLF
"." CRLF
「日付答え=「511[answertext]インチCRLFテキストCRLF」。」 CRLF
Grau, et al. Experimental [Page 13] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[13ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
date-answer =/ "300" [answertext] CRLF
utc-time [answertext] CRLF
"." CRLF
「日付答え=/「300[answertext]インチCRLF utc-時間[answertext]CRLF」。」 CRLF
Examples
例
<-- DATE
--> 300
19990427135230 UTC
.
<--デートしてください-->300 19990427135230UTC。
<-- DATE
--> 511
Time is unknown
.
<--DATE-->511Timeは未知です。
6.3.3.4. VERS
6.3.3.4. VERS
Description
記述
The VERS command is used to determine the protocol level to use between client and server. The parameter is a protocol level that the client supports and wants to use. The server will respond with the highest level accepted. This version number MUST not be higher than that requested by the client. Client and server MUST only use commands from the level that the server has confirmed. It is possible, but seldom necessary, to change the protocol level during a session by client request (VERS [protocol level]). When no option is given, the current protocol level will be printed. When no protocol level is negotiated, the protocol level 1 will be used. Commands of a higher level are not allowed without successful negotiation. The protocol level can be followed by an optional comment.
VERSコマンドは、サーバクライアントとパラメタの間で使用するプロトコルレベルがクライアントが支持して、使用したがっているプロトコルレベルであることを決定するのに使用されます。 サーバは最高水準を受け入れていて反応するでしょう。 このバージョン番号はクライアントによって要求されたそれより大きいはずがありません。 クライアントとサーバはサーバが確認したレベルからコマンドを使用するだけでよいです。 それは、クライアント要求(VERS[プロトコルレベル])でセッションの間、プロトコルレベルを変えるのに可能ですが、めったに必要ではありません。 オプションを全く与えないとき、現在のプロトコルレベルを印刷するでしょう。 プロトコルレベルが全く交渉されないとき、プロトコルレベル1は使用されるでしょう。 より高いレベルのコマンドはうまくいっている交渉なしで許容されていません。 任意のコメントはプロトコルレベルのあとに続くことができます。
vers-cmd = "VERS" [WSP level] CRLF
vers-cmdは「VERS」[WSPレベル]CRLFと等しいです。
level = 1*5DIGIT ; the valid range is 1 - 32767
レベルは1*5DIGITと等しいです。 有効枠は1--32767です。
Possible answers
可能な答え
202: Returns current protocol level 302: Requested level accepted 402: Requested level too high; falling back to lower level 510: Syntax error
202: 電流が議定書の中で述べるリターンは302を平らにします: 要求されたレベルは402を受け入れました: レベルをあまり高く要求します。 下ろすために後ろへ下がって、510を平らにしてください: 構文エラー
vers-answer = "202" [answertext] CRLF
level [answertext] CRLF
"." CRLF
「vers-答え=「202[answertext]インチCRLFレベル[answertext]CRLF」。」 CRLF
Grau, et al. Experimental [Page 14] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[14ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
vers-answer =/ "302" [answertext] CRLF
level [answertext] WSP level CRLF
"." CRLF
vers-answer =/ "402" [answertext] CRLF
level [answertext] WSP level CRLF
"." CRLF
vers-answer =/ "510" [answertext] CRLF
level [answertext] CRLF
"." CRLF
「vers-答え=/「302[answertext]のインチCRLFの平らな[answertext]WSP平らなCRLF」。」 「CRLF vers-答え=/「402[answertext]のインチCRLFの平らな[answertext]WSP平らなCRLF」。」 「CRLF vers-答え=/「510[answertext]インチCRLFレベル[answertext]CRLF」。」 CRLF
Examples
例
<-- VERS
--> 202
2 Current protocol level is 2
.
<--VERS-->202 2Currentプロトコルレベルは2です。
<-- VERS 2
--> 302
2 My max protocol level is 10
.
<--VERS2-->302 2My最大プロトコルレベルは10です。
<-- VERS 11
--> 402
10 Falling back to level 10
.
>402 10Fallingがレベル10に支持する<(VERS11)。
<-- VERS BAL
--> 510
1 Syntax error
.
<--VERS BAL-->の510の1Syntaxの誤り。
6.3.3.5. QUIT
6.3.3.5. やめてください。
Description
記述
Terminates the connection.
接続を終えます。
quit-cmd = "QUIT" CRLF
cmdをやめている=「やめてください」CRLF
Possible answers
可能な答え
201: Termination of the connection
201: 接続の終了
quit-answer = "201" [answertext] CRLF
答えをやめている=「201」[answertext]CRLF
Grau, et al. Experimental [Page 15] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[15ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Example
例
<-- QUIT --> 201 Closing connection. Bye.
<--QUIT-->201Closing接続。 さようなら。
6.3.3.6. LIST
6.3.3.6. リスト
Description
記述
To obtain a list of newsgroups and sub-hierarchies in the requested hierarchies, the command LIST is used. The status of the hierarchies is also given. The highest level consists of all top-level hierarchies and is labeled "*". It can be obtained this way, too.
要求された階層構造でニュースグループとサブ階層構造のリストを得るために、コマンドLISTは使用されています。 また、階層構造の状態を与えます。 最高水準は、すべてのトップレベル階層構造から成って、「*」とラベルされます。 この道にもそれを得ることができます。
The data consist of a newsgroup- or hierarchy-name/status indicator pair per line. Name and status indicator must be separated by at least one white space. The status indicator is a single word (see Section 6.4). The interpretation is not case sensitive.
データは1線あたり1ニュースグループか階層構造名/自動運転表示灯組から成ります。 少なくとも1つの余白で名前と自動運転表示灯を切り離さなければなりません。 自動運転表示灯は一語(セクション6.4を見る)です。 解釈は大文字と小文字を区別していません。
list-cmd = "LIST" ( WSP "*" / 1*(WSP name)) CRLF
リスト-cmdは「リスト」(WSP「*」/1*(WSP名))CRLFと等しいです。
Possible answers
可能な答え
401: Permission denied 510: Syntax error 610: Normal response with all requested data
401: 許可は510を否定しました: 構文エラー610: すべてがある通常の応答はデータを要求しました。
list-answer = "610" [answertext] CRLF
*(listdata CRLF)
"." CRLF
list-answer =/ "401" [answertext] CRLF
text CRLF
"." CRLF
list-answer =/ "510" [answertext] CRLF
text CRLF
"." CRLF
「リスト答えは「610[answertext]インチCRLF*(listdata CRLF)」と等しいです。」 「CRLFリスト答え=/「401インチ[answertext]CRLFテキストCRLF」。」 「CRLFリスト答え=/「510インチ[answertext]CRLFテキストCRLF」。」 CRLF
listdata = name WSP list-status
listdataは名前WSPリスト状態と等しいです。
The list-status is the status of a newsgroup or hierarchy according to Section 6.4.
リスト状態はセクション6.4に従ったニュースグループか階層構造の状態です。
list-status = "Complete" /
"Incomplete" /
"Obsolete" /
"Unknown" /
"Unmoderated" /
"Readonly" /
リスト状態は「完全である」か「不完全である」か「時代遅れ」の、または、「未知」の/"Unmoderated"/"Readonly"/と等しいです。
Grau, et al. Experimental [Page 16] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[16ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
"Moderated" /
"Removed" ; list-status is case-insensitive
「加減される」か、または「取り除かれます」。 リスト状態は大文字と小文字を区別しないです。
Examples
例
<-- LIST *
--> 610 data follow
alt Incomplete
comp Complete
de Incomplete
rec Complete
sub Obsolete
.
<--LIST*-->610データはalt IncompleteコンピュータComplete de Incomplete rec Complete潜水艦Obsoleteに続きます。
<-- LIST de
--> 610 data follow
de.admin Complete
de.alt Incomplete
de.comm Complete
de.comp Complete
de.etc Complete
de.markt Complete
de.newusers Complete
de.org Complete
de.rec Complete
de.sci Complete
de.soc Complete
de.answers Moderated
de.test Unmoderated
.
<--LIST de-->610データはde.admin Complete de.alt Incomplete de.comm Complete de.comp Complete de.etc Complete de.markt Complete de.newusers Complete de.org Complete de.rec Complete de.sci Complete de.soc Complete de.answers Moderated de.test Unmoderatedに続きます。
<-- LIST foo
--> 610 data follow
foo Unknown
.
<--LIST foo-->610データはfoo Unknownに続きます。
<-- LIST
--> 510 Syntax error
missing parameter hierarchy
.
<--LIST-->の510のSyntaxの誤りのなくなったパラメタ階層構造。
<-- LIST de
--> 401 Something is wrong
Permission denied
.
<--LIST de-->401Somethingは否定された間違ったPermissionです。
Grau, et al. Experimental [Page 17] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[17ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
6.3.3.7. LSTR
6.3.3.7. LSTR
Description
記述
To obtain a recursive list of newsgroups and sub-hierarchies in the named hierarchy, the command LSTR is used. The status of the hierarchies is also given. The highest level consists of all top- level hierarchies and is labeled "*". It can be obtained this way, too.
命名された階層構造でニュースグループとサブ階層構造の再帰的なリストを得るために、コマンドLSTRは使用されています。 また、階層構造の状態を与えます。 最高水準は、すべての最高平らな階層構造から成って、「*」とラベルされます。 この道にもそれを得ることができます。
The use of "*" as a wildcard pattern following the beginning of a hierarchy name is also possible; so a "LSTR de.a*" would return a list of all newsgroups and hierarchies starting with "de.a".
また、階層構造名の始まりに続くワイルドカードパターンとしての「*」の使用も可能です。 それで、"de.a"から始めて、「LSTR de.a*」はすべてのニュースグループと階層構造のリストを返すでしょう。
lstr-cmd = "LSTR" ( WSP "*" / 1*(WSP name ["*" / ".*"]) ) CRLF
「lstr-cmdが"LSTR"と等しい、(WSP「*」/1*、(WSPが命名する、[「*」/、」 . *、」、)、CRLF
Possible answers
可能な答え
401: Permission denied 510: Syntax error 610: Normal answer with all requested data
401: 許可は510を否定しました: 構文エラー610: すべてがある通常の答えはデータを要求しました。
lstr-answer = "610" [answertext] CRLF
*(listdata CRLF)
"." CRLF
lstr-answer =/ "401" [answertext] CRLF
text CRLF
"." CRLF
lstr-answer =/ "510" [answertext] CRLF
text CRLF
"." CRLF
「lstr-答えは「610[answertext]インチCRLF*(listdata CRLF)」と等しいです。」 「CRLF lstr-答え=/「401インチ[answertext]CRLFテキストCRLF」。」 「CRLF lstr-答え=/「510インチ[answertext]CRLFテキストCRLF」。」 CRLF
listdata = name WSP list-status
listdataは名前WSPリスト状態と等しいです。
The list-status is the status of a newsgroup or hierarchy according to Section 6.4.
リスト状態はセクション6.4に従ったニュースグループか階層構造の状態です。
list-status = "Complete" /
"Incomplete" /
"Obsolete" /
"Unknown" /
"Unmoderated" /
"Readonly" /
"Moderated" /
"Removed" ; list-status is case-insensitive
リスト状態は「完全である」か「不完全である」か「時代遅れ」の/と「加減される」か「未知」/"Unmoderated"/"Readonly"/「取り除かれた」状態で等しいです。 リスト状態は大文字と小文字を区別しないです。
Grau, et al. Experimental [Page 18] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[18ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Example
例
<-- LSTR de.admin
--> 610 recursive mode
de.admin Complete
de.admin.infos Moderated
de.admin.lists Moderated
de.admin.misc Unmoderated
de.admin.net-abuse Complete
de.admin.net-abuse.announce Moderated
de.admin.net-abuse.mail Unmoderated
de.admin.net-abuse.misc Unmoderated
de.admin.net-abuse.news Unmoderated
de.admin.news Complete
de.admin.news.announce Moderated
de.admin.news.groups Unmoderated
de.admin.news.misc Unmoderated
de.admin.news.nocem Unmoderated
de.admin.news.regeln Unmoderated
.
<--LSTR de.admin-->の610の再帰的なモードde.admin Complete de.admin.infos Moderated de.admin.lists Moderated de.admin.misc Unmoderated de.admin.net-乱用Complete de.admin.net-abuse.announce Moderated de.admin.net-abuse.mail Unmoderated de.admin.net-abuse.misc Unmoderated de.admin.net-abuse.news Unmoderated de.admin.news Complete de.admin.news.announce Moderated de.admin.news.groups Unmoderated de.admin.news.misc Unmoderated de.admin.news.nocem Unmoderated de.admin.news.regeln Unmoderated。
6.3.3.8. HIER
6.3.3.8. HIER
Description
記述
The command HIER lists all information available about the hierarchy.
With the data header "Name", a new data block for each hierarchy is
started. The header "Name" gives the name of the hierarchy. The
data headers are described in Section 6.3.4. The default is to
transmit all available information. It can be limited to a list of
desired headers ("Name" and "Status" are always given). A set of
comma-separated headers, as an option to the HIER command, will
return the requested header fields.
コマンドHIERは階層構造に関して利用可能なすべての情報をリストアップします。 ヘッダー「名前」というデータから、各階層構造のための新しいデータ・ブロックは始動されます。 ヘッダー「名前」は階層構造の名前を与えます。 データヘッダーはセクション6.3.4で説明されます。 デフォルトはすべての入手可能な情報を伝えることです。 それを必要なヘッダーのリストに制限できます(いつも「名前」と「状態」を与えます)。 HIERコマンドへのオプションとして、1セットのコンマで切り離されたヘッダーは要求されたヘッダーフィールドを返すでしょう。
hier-cmd = "HIER" 1*(WSP name) [WSP selection] CRLF
hier-cmdは"HIER"1*(WSP名)[WSP選択]CRLFと等しいです。
selection = *( "," header ) ; Describes the data fields
; that are requested
header = ALPHA *( ALPHA / "-" ) ; According to section 6.3.4
選択が*と等しい、(「」、ヘッダー)、。 データ・フィールドについて説明します。 それは要求されたヘッダー=アルファー*です(アルファー/「-」)。 セクション6.3.4に従って
Example for selection
選択のための例
,Followup,Description : For all entries list Name, Status, Followup
and Description
追跡、記述: すべてのエントリーリストName、Status、Followup、および記述のために
Possible answers
可能な答え
401: Permission denied
401: 否定された許可
Grau, et al. Experimental [Page 19] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[19ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
510: Syntax error 611: Regular answer with all requested data
510: 構文エラー611: すべてがある定期的な答えはデータを要求しました。
hier-answer = "611" [answertext] CRLF
*(hierdata CRLF)
"." CRLF
hier-answer =/ "510" [answertext] CRLF
*(text CRLF)
"." CRLF
hier-answer =/ "401" [answertext] CRLF
*(text CRLF)
"." CRLF
「hier-答えは「611[answertext]インチCRLF*(hierdata CRLF)」と等しいです。」 「CRLF hier-答え=/「510[answertext]インチCRLF*(テキストCRLF)」。」 「CRLF hier-答え=/「401[answertext]インチCRLF*(テキストCRLF)」。」 CRLF
hierdata = "Name:" WSP text CRLF
"Status:" WSP text CRLF
*(header ":" WSP text CRLF)
[("Ctl-PGP-Key:" CRLF PGP-answer /
"Mod-PGP-Key:" CRLF PGP-answer)]
hierdata=は「以下を命名します」。 WSPテキストCRLF、「状態:」 「WSPテキストCRLF*(ヘッダー」 : 」 WSPテキストCRLF)(「以下をCtl-PGP合わせてください」、「PGPが合わせるモッズ:」 CRLF PGP-答えに/にCRLF PGP答えてください、]
PGP-answer: The exact format is described in Section 6.7.
PGP-答え: 正確な形式はセクション6.7で説明されます。
Examples
例
<-- HIER de
--> 611 Data coming
Name: de
Status: Complete
Serial: 20020823120306
Description: Internationale deutschsprachige Newsgruppen
Netiquette: http://www.kirchwitz.de.example/~amk/dni/netiquette
FAQ: http://www.kirchwitz.de.example/~amk/dai/einrichtung
Ctl-Send-Adr: moderator@dana.de.example
Ctl-Newsgroup: de.admin.news.announce
Mod-Wildcard: %s@moderators.dana.de.example
Language: DE
Charset: ISO-8859-1
Encoding: text/plain
Newsgroup-Type: Discussion
Hier-Type: Global
Comp-Length: 14
Date-Create: 19920106000000
<--HIER de-->の611のDataの次のName: de Status: シリーズを完成してください: 20020823120306記述: インターナショナルdeutschsprachige Newsgruppen Netiquette: http://www.kirchwitz.de.example/~amk/dni/netiquette FAQ: http://www.kirchwitz.de.example/~amk/dai/einrichtung 、CtlはAdrを送ります: moderator@dana.de.example Ctl-Newsgroup: de.admin.news.announce Mod-ワイルドカード: %s@moderators.dana.de.example 言語: DE Charset: ISO-8859-1コード化: 明瞭なニュースグループテキスト/タイプ: 議論Hier-タイプ: グローバルなコンピュータ長さ: 14は以下を日付で作成します。 19920106000000
.
.
<-- HIER bln
--> 401
Permission denied
.
>401Permissionが否定した<(HIER十億)。
Grau, et al. Experimental [Page 20] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[20ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
<-- HIER
--> 510 Syntax error
missing parameter hierarchy
.
<--HIER-->の510のSyntaxの誤りのなくなったパラメタ階層構造。
6.3.3.9. DATA
6.3.3.9. データ
Description
記述
The DATA command corresponds to the HIER command, as explained in 6.3.3.8, but it is used for information about a newsgroup. A summary of codes can be found in Section 6.3.4.
DATAコマンドはHIERコマンドに対応しています、説明されるように6.3、.3、.8、それだけがニュースグループの情報に使用されます。 セクション6.3.4でコードの概要を見つけることができます。
data-cmd = "DATA" 1*(WSP name) [WSP selection] CRLF
データ-cmdは「データ」1*(WSP名)[WSP選択]CRLFと等しいです。
Possible answers
可能な答え
401: Permission denied 510: Syntax error 612: Regular answer with all requested data
401: 許可は510を否定しました: 構文エラー612: すべてがある定期的な答えはデータを要求しました。
data-answer = "612" [answertext] CRLF
*(datadata CRLF)
"." CRLF
data-answer =/ "510" [answertext] CRLF
text CRLF
"." CRLF
data-answer =/ "401" [answertext] CRLF
text CRLF
"." CRLF
「データ答えは「612[answertext]インチCRLF*(datadata CRLF)」と等しいです。」 「CRLFデータ答え=/「510インチ[answertext]CRLFテキストCRLF」。」 「CRLFデータ答え=/「401インチ[answertext]CRLFテキストCRLF」。」 CRLF
datadata = "Name:" WSP text CRLF
"Status:" WSP text CRLF
*(header ":" WSP text CRLF)
[("Ctl-PGP-Key:" CRLF PGP-answer /
"Mod-PGP-Key:" CRLF PGP-answer)]
datadata=は「以下を命名します」。 WSPテキストCRLF、「状態:」 「WSPテキストCRLF*(ヘッダー」 : 」 WSPテキストCRLF)(「以下をCtl-PGP合わせてください」、「PGPが合わせるモッズ:」 CRLF PGP-答えに/にCRLF PGP答えてください、]
Examples
例
<-- DATA de.comp.os.unix.linux.moderated
--> 612 data follow
Name: de.comp.os.unix.linux.moderated
Status: Moderated
Serial: 20020823120312
Description: Linux und -Distributionen.
<dcoulm-moderators@linux-config.de.example>
Charter: http://www.dana.de.example/mod/chartas/de.html
Netiquette: http://www.kirchwitz.de.example/~amk/dni/netiquette
<--DATA de.comp.os.unix.linux.moderated-->612データはNameに続きます: de.comp.os.unix.linux.moderated Status: シリーズを加減します: 20020823120312記述: リナックスund -Distributionen。 >がチャーターする<config.de.example dcoulm-議長@linux-: http://www.dana.de.example/mod/chartas/de.html ネチケット: http://www.kirchwitz.de.example/~amk/dni/netiquette
Grau, et al. Experimental [Page 21] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[21ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Netiquette: ftp://ftp.fu-berlin.de.example/doc/usenet/german
/Netiquette
Mod-Sub-Adr: dcoulm-moderators@linux-config.de.example
Mod-Group-Info: http://wpxx02.toxi.uni-wuerzburg.de.example
/~dcoulmod/
Newsgroup-Type: Discussion
ネチケット: ネチケットのモッズ風のサブ ftp://ftp.fu-berlin.de.example/doc/usenet/german /Adr: dcoulm-moderators@linux-config.de.example モッズグループインフォメーション: http://wpxx02.toxi.uni-wuerzburg.de.example /~ニュースグループdcoulmod/タイプ: 議論
.
.
<-- DATA de.foo
--> 612 data follow
Name: de.foo
Status: Unknown
<--DATA de.foo-->612データはNameに続きます: de.foo Status: 未知
.
.
<-- DATA de
--> 401
Permission denied
.
>401Permissionが否定した<(DATA de)。
<-- DATA
--> 510 Syntax error
missing parameter newsgroup
.
<--DATA-->の510のSyntaxの誤りのなくなったパラメタニュースグループ。
6.3.3.10. GETP
6.3.3.10. GETP
Description
記述
GETP is used for server-server communication. It requests the data for the hierarchy specified by the parameter "name". The format of the data is the same as for the commands "HIER" and "LIST". If "*" is given as hierarchy name, all data the server is offering will be transmitted.
GETPはサーバサーバコミュニケーションに使用されます。 それは、階層構造のためのデータが「名前」というパラメタで指定したよう要求します。 データの形式はコマンド"HIER"と「リスト」のように同じです。 階層構造名として「*」を与えると、サーバが提供しているすべてのデータを送るでしょう。
The "timestamp" attached to a package consists of the date and time that the package was created. The timestamp for a package is transmitted together with the package data by the server and marks a specific revision for the package data.
パッケージに付けられた「タイムスタンプ」はパッケージが作成された日時から成ります。 パッケージのためのタイムスタンプは、パッケージデータと共にサーバによって伝えられて、パッケージデータのために特定の改正をマークします。
When a client requests a package with GETP, it transmits the timestamp attached to the package in its database so that the server can check whether the data on the client side is still valid or if it is too old. If the data on the client side is still valid, a 213 answer is sent, so the client knows that its data is OK. If the timestamp is "0", the server is forced to transmit the data.
クライアントがGETPと共にパッケージを要求するとき、それはサーバが、クライアント側の上のデータがまだ有効であるかどうか、またはそれが古過ぎるかどうかチェックできるようにデータベースでのパッケージに添付されたタイムスタンプを伝えます。 クライアント側の上のデータがまだ有効であるなら、213答えを送るので、クライアントは、データがOKであることを知っています。 タイムスタンプが「何0インチも、サーバはやむを得ずデータを送る」ということであるなら。
Grau, et al. Experimental [Page 22] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[22ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Timestamps set by the server must be increasing and may not be more than 12 hours in the future.
サーバによって設定されたタイムスタンプは、増加でなければならなく、将来、12時間以上でないかもしれません。
The data for a successful request are signed and sent in ASCII armor according to [RFC2440], so a client can check the signature or ignore it. The actual data will be surrounded by the armor start and end sections, according to Section 6.2 of [RFC2440].
[RFC2440]に応じて、ASCIIよろいかぶとでうまくいっている要求のためのデータにサインして、送るので、クライアントは、署名をチェックするか、またはそれを無視できます。 [RFC2440]のセクション6.2によると、実際のデータはよろいかぶと始めと端面によって囲まれるでしょう。
getp-cmd = "GETP" WSP username WSP password WSP timestamp
WSP ( name / "*" ) CRLF
getp-cmdは"GETP"WSPユーザ名WSPパスワードWSPタイムスタンプWSP(名前/「*」)CRLFと等しいです。
username = *1( VCHAR ) / "0" ; Length of VCHAR >= 1
ユーザ名=*1(VCHAR)/「0インチ」。 VCHAR>=1の長さ
password = *1( VCHAR ) / "0" ; Length of VCHAR >= 1
パスワード=*1(VCHAR)/「0インチ」。 VCHAR>=1の長さ
timestamp = utc-time / ; date and time of the last retrieval
"0" ; force the transmission of data
タイムスタンプはutc-時間/と等しいです。 最後の検索「0インチ」の日時。 データの伝達を強制してください。
Possible answers
可能な答え
213: Current data at the client side 411: No hierarchy with that name 430: Permission denied 510: Syntax error 613: Hierarchy data
213: クライアントの現在のデータは411に面があります: それがある階層構造も、全く430は命名しません: 許可は510を否定しました: 構文エラー613: 階層構造データ
getp-answer = "613" [answertext] CRLF
pgp-ascii-armor-start ; this is according to [RFC2440]
*(getpdata CRLF)
pgp-ascii-armor-end ; this is according to [RFC2440]
"." CRLF
getp-answer =/ "213" [answertext] CRLF
text CRLF
"." CRLF
getp-answer =/ "430" [answertext] CRLF
text CRLF
"." CRLF
getp-answer =/ "411" [answertext] CRLF
text CRLF
"." CRLF
getp-answer =/ "510" [answertext] CRLF
text CRLF
"." CRLF
getp-答えは「613」[answertext]CRLF pgp ASCIIよろいかぶと始めと等しいです。 [RFC2440]*(getpdata CRLF)pgp ASCIIよろいかぶとエンドに従って、これはあります。 「[RFC2440]に従って、これはある」、」 「CRLF getp-答え=/「213インチ[answertext]CRLFテキストCRLF」。」 「CRLF getp-答え=/「430インチ[answertext]CRLFテキストCRLF」。」 「CRLF getp-答え=/「411インチ[answertext]CRLFテキストCRLF」。」 「CRLF getp-答え=/「510インチ[answertext]CRLFテキストCRLF」。」 CRLF
pgp-ascii-armor-start and the pgp-ascii-armor-end are built according to [RFC2440], Section 6.2., "Forming ASCII Armor".
「ASCIIよろいかぶとを形成し」て、[RFC2440]、セクション6.2.によると、pgp ASCIIよろいかぶと開始とpgp ASCIIよろいかぶとエンドは造られます。
Grau, et al. Experimental [Page 23] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[23ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
getpdata = "Name:" WSP text CRLF
"Status:" WSP text CRLF
"Serial:" WSP timestamp CRLF
*(header ":" WSP text CRLF)
[("Ctl-PGP-Key:" CRLF PGP-answer /
"Mod-PGP-Key:" CRLF PGP-answer)]
getpdata=は「以下を命名します」。 WSPテキストCRLF、「状態:」 WSPテキストCRLF、「シリーズ:」 「WSPタイムスタンプCRLF*(ヘッダー」 : 」 WSPテキストCRLF)(「以下をCtl-PGP合わせてください」、「PGPが合わせるモッズ:」 CRLF PGP-答えに/にCRLF PGP答えてください、]
Examples
例
<-- GETP 0 0 0 humanities
--> 615 data follow
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
<--GETP0 0 0人文科学-->615データは従います。-----始まり、PGPはメッセージにサインしました。----- 細切れ肉料理: SHA1
Name: humanities
Status: Complete
Serial: 20020821094529
Description: Branches of learning that investigate human
constructs and concerns as opposed to natural processes.
Netiquette: ftp://rtfm.mit.edu.example/pub/usenet
/news.announce.newusers
/A_Primer_on_How_to_Work_With_the_Usenet_Community
Rules: http://www.uvv.org.example/docs/howto.txt
Ctl-Send-Adr: group-admin@isc.org.example
Ctl-Newsgroup: news.announce.newgroup
Language: EN
Charset: US-ASCII
Encoding: text/plain
Newsgroup-Type: Discussion
Hier-Type: Global
Comp-Length: 14
Date-Create: 19950417143009
以下を命名してください。 人文科学Status: シリーズを完成してください: 20020821094529記述: それについて知る支店はナチュラル・プロセスと対照的に人間の構造物と関心を調査します。 ネチケット: ____Usenet_共同体がある仕事_への_がどう統治されるかに関する ftp://rtfm.mit.edu.example/pub/usenet /news.announce.newusers /A_入門書_: http://www.uvv.org.example/docs/howto.txt 、CtlはAdrを送ります: group-admin@isc.org.example Ctl-Newsgroup: news.announce.newgroup Language: アンCharset: 米国-ASCIIコード化: 明瞭なニュースグループテキスト/タイプ: 議論Hier-タイプ: グローバルなコンピュータ長さ: 14は以下を日付で作成します。 19950417143009
Name: humanities.answers
Status: Moderated
Serial: 20020821094533
Description: Repository for periodic USENET articles. (Moderated)
Mod-Sub-Adr: news-answers@mit.edu.example
Mod-Adm-Adr: news-answers-request@mit.edu.example
Newsgroup-Type: Announce
Date-Create: 19950725182040
Name: humanities.classics
[...]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (IRIX64)
以下を命名してください。 humanities.answers Status: シリーズを加減します: 20020821094533記述: 周期的なUSENET記事のための倉庫。 (加減されます) モッズサブAdr: news-answers@mit.edu.example モッズ-Adm-Adr: news-answers-request@mit.edu.example ニュースグループタイプ: 以下を日付で作成するように発表してください。 19950725182040名: humanities.classics[…] -----PGP署名を始めてください。----- バージョン: GnuPG v1.0.7(IRIX64)
iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH
rRynPhhjveiY/XBkkrrZFho=
iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH rRynPhhjveiY/XBkkrrZFho=
Grau, et al. Experimental [Page 24] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[24ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
=muK4
-----END PGP SIGNATURE-----
.
=muK4-----終わりのPGP署名----- .
<-- GETP 0 0 19990909101000 de
--> 213
You are up-to-date
.
<--GETP0 0 19990909101000de-->213、最新です。
<-- GETP foo
--> 510 Syntax error
Missing parameters
.
<--GETP foo-->510Syntax誤りMissingパラメタ。
<-- GETP guest test 0 de
--> 430
You have no permission to retrieve the data
.
<--GETP客テスト0de--あなたが許可を全く持っていない>430はデータを検索します。
6.3.3.11. GETA
6.3.3.11. 下駄
Description
記述
The GETA command is used for server-server communication; it is used to collect authoritative data and will request packages that the server is authoritative for. A package is the authoritative data either for a newsgroup or a hierarchy. Each package has a "timestamp" attached to mark the revision of the package. This timestamp is set by the server to the date of the last modification of the package data in UTC format. A timestamp of "0" indicates that the package MUST be retrieved. If the retrieving client has a recent package (i.e., no modification on the authoritative server), the server sends only a 215 response. The format of the data is the same as that for the commands "HIER" and "LIST".
GETAコマンドはサーバサーバコミュニケーションに使用されます。 それは、信頼すべきデータを集めるのに使用されて、サーバが正式であるパッケージを要求するでしょう。 パッケージはニュースグループか階層構造のための信頼すべきデータです。 各パッケージで、パッケージの改正をマークするために「タイムスタンプ」を付けます。 このタイムスタンプはUTC形式における、パッケージデータの最後の変更の日付までのサーバによるセットです。 「0インチは、パッケージを検索しなければならないのを示す」タイムスタンプ。 検索しているクライアントに最近のパッケージ(すなわち、正式のサーバにおける変更がない)があるなら、サーバは215応答だけを送ります。 データの形式はコマンド"HIER"と「リスト」のためのそれと同じです。
geta-cmd = "GETA" WSP username WSP password WSP
timestamp WSP name CRLF
下駄-cmdは「下駄」WSPユーザ名WSPパスワードWSPタイムスタンプWSP名前CRLFと等しいです。
Possible answers
可能な答え
215: The client already has the current data 430: Permission denied 411: No hierarchy with that name 510: Syntax error 615: Regular answer with all requested data
215: クライアントには、現在のデータ430が既にあります: 許可は411を否定しました: それがある階層構造も、全く510は命名しません: 構文エラー615: すべてがある定期的な答えはデータを要求しました。
Grau, et al. Experimental [Page 25] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[25ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
geta-answer = "615" [answertext] CRLF
pgp-ascii-armor-start ; this is according to [RFC2440]
*(getadata CRLF)
pgp-ascii-armor-end ; this is according to [RFC2440]
"." CRLF
geta-answer =/ "215" [answertext] CRLF
text CRLF
"." CRLF
geta-answer =/ "430" [answertext] CRLF
text CRLF
"." CRLF
geta-answer =/ "411" [answertext] CRLF
text CRLF
"." CRLF
geta-answer =/ "510" [answertext] CRLF
text CRLF
"." CRLF
下駄答えは「615」[answertext]CRLF pgp ASCIIよろいかぶと始めと等しいです。 [RFC2440]*(getadata CRLF)pgp ASCIIよろいかぶとエンドに従って、これはあります。 「[RFC2440]に従って、これはある」、」 「CRLF下駄答え=/「215インチ[answertext]CRLFテキストCRLF」。」 「CRLF下駄答え=/「430インチ[answertext]CRLFテキストCRLF」。」 「CRLF下駄答え=/「411インチ[answertext]CRLFテキストCRLF」。」 「CRLF下駄答え=/「510インチ[answertext]CRLFテキストCRLF」。」 CRLF
getadata = "Name:" WSP text CRLF
"Status:" WSP text CRLF
"Serial:" WSP timestamp CRLF
*(header ":" WSP text CRLF)
[("Ctl-PGP-Key:" CRLF PGP-answer/
"Mod-PGP-Key:" CRLF PGP-answer)]
getadata=は「以下を命名します」。 WSPテキストCRLF、「状態:」 WSPテキストCRLF、「シリーズ:」 「WSPタイムスタンプCRLF*(ヘッダー」 : 」 WSPテキストCRLF)(「以下をCtl-PGP合わせてください」、「PGPが合わせるモッズ:」 CRLF PGP-答えに/にCRLF PGP答えてください、]
Example
例
<-- GETA 0 0 0 humanities
--> 613 data follow
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
<--GETA0 0 0人文科学-->613データは従います。-----始まり、PGPはメッセージにサインしました。----- 細切れ肉料理: SHA1
Name: humanities
Status: Complete
Serial: 20020821094529
Description: Branches of learning that investigate human
constructs and concerns as opposed to natural processes.
Netiquette: ftp://rtfm.mit.edu.example/pub/usenet
/news.announce.newusers
/A_Primer_on_How_to_Work_With_the_Usenet_Community
Rules: http://www.uvv.org.example/docs/howto.txt
Ctl-Send-Adr: group-admin@isc.org.example
Ctl-Newsgroup: news.announce.newgroup
Language: EN
Charset: US-ASCII
Encoding: text/plain
Newsgroup-Type: Discussion
Hier-Type: Global
以下を命名してください。 人文科学Status: シリーズを完成してください: 20020821094529記述: それについて知る支店はナチュラル・プロセスと対照的に人間の構造物と関心を調査します。 ネチケット: ____Usenet_共同体がある仕事_への_がどう統治されるかに関する ftp://rtfm.mit.edu.example/pub/usenet /news.announce.newusers /A_入門書_: http://www.uvv.org.example/docs/howto.txt 、CtlはAdrを送ります: group-admin@isc.org.example Ctl-Newsgroup: news.announce.newgroup Language: アンCharset: 米国-ASCIIコード化: 明瞭なニュースグループテキスト/タイプ: 議論Hier-タイプ: グローバル
Grau, et al. Experimental [Page 26] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[26ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Comp-Length: 14
Date-Create: 19950417143009
コンピュータ長さ: 14は以下を日付で作成します。 19950417143009
Name: humanities.answers
Status: Moderated
Serial: 20020821094533
Description: Repository for periodic USENET articles. (Moderated)
Mod-Sub-Adr: news-answers@mit.edu.example
Mod-Adm-Adr: news-answers-request@mit.edu.example
Newsgroup-Type: Announce
Date-Create: 19950725182040
以下を命名してください。 humanities.answers Status: シリーズを加減します: 20020821094533記述: 周期的なUSENET記事のための倉庫。 (加減されます) モッズサブAdr: news-answers@mit.edu.example モッズ-Adm-Adr: news-answers-request@mit.edu.example ニュースグループタイプ: 以下を日付で作成するように発表してください。 19950725182040
Name: humanities.classics
[...]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (IRIX64)
以下を命名してください。 humanities.classics[…] -----PGP署名を始めてください。----- バージョン: GnuPG v1.0.7(IRIX64)
iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH
rRynPhhjveiY/XBkkrrZFho=
=muK4
-----END PGP SIGNATURE-----
.
iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH rRynPhhjveiY/XBkkrrZFho= =muK4-----終わりのPGP署名----- .
6.3.3.12. Unknown Commands and Syntax Errors
6.3.3.12. 未知のコマンドと構文エラー
If a command is recognized as unknown, a 519 return code (unknown command) is given. If an error occurs after the command string (e.g., a missing parameter), a 510 return code (Syntax error: Missing parameter) is given.
同じくらい未知でコマンドを認識するなら、519復帰コード(未知のコマンド)を与えます。 誤りがコマンドストリング(例えば、なくなったパラメタ)の後に発生するなら、510復帰コード(構文エラー: なくなったパラメタ)を与えます。
6.3.4. Data Headers
6.3.4. データヘッダー
The following paragraphs describe key words and key terms that support retrieval and storing of information. Every header has a unique English name.
以下のパラグラフは情報の検索と格納を支持するキーワードと主要な用語について説明します。 すべてのヘッダーには、ユニークなイギリスの名前があります。
The content of a header is inheritable within a hierarchy, as long as
ヘッダーが階層構造の中で相続可能であって、長いaの内容
the header is marked as inheritable. The content is the default value for all downstream newsgroups and sub-hierarchies. For example, in the hierarchy "de", the language header has the value "DE" (German); therefore, this value is "DE" for all newsgroups in this hierarchy, except for those that explicitly define a language code of their own.
ヘッダーは相続可能であるとしてマークされます。 内容はすべての川下のニュースグループとサブ階層構造のためのデフォルト値です。 例えば、階層構造"de"では、言語ヘッダーは値「DE」を(ドイツ)であるのに持っています。 したがって、この値はこの階層構造においてすべてのニュースグループのための「DE」です、明らかにそれら自身の言語コードを定義するものを除いて。
Hierarchies and newsgroups must have at least values for the headers "Name" and "Status". Unknown hierarchies or groups get the status "Unknown".
階層構造とニュースグループには、少なくともヘッダー「名前」と「状態」への値がなければなりません。 未知の階層構造かグループが「未知」に状態を得ます。
Grau, et al. Experimental [Page 27] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[27ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
The header used in the NAS protocol are not case sensitive. A header may be uppercase, lowercase, or any mixture of upper- and lowercase. It is recommended that the first letter of the header and the first letter after a dash be uppercase and that all other characters be lowercase.
NASプロトコルに使用されるヘッダーは大文字と小文字を区別していません。 ヘッダーは、大文字して、小文字であって上側のどんな混合物でありも、小文字で印刷するかもしれません。 ヘッダーの最初の手紙とダッシュの後の最初の文字が大文字していて、他のすべてのキャラクタが小文字であることは、お勧めです。
Name
名前
Header: Name
ヘッダー: 名前
Used for: hierarchy Mandatory: yes Inheritable: no Repeatable: no Description: Name of a hierarchy. Comment: Start of a new data block. Example: Name: comp
以下に使用されました。 階層構造Mandatory: はいInheritable: Repeatableがありません: 記述がありません: 階層構造の名前。 コメント: 新しいデータ・ブロックの始まり。 例: 以下を命名してください。 コンピュータ
Used for: newsgroup Mandatory: yes Repeatable: no Description: Name of a newsgroup Comment: Start of a new data block. Example: Name: de.admin.news.announce
以下に使用されました。 ニュースグループMandatory: はいRepeatable: 記述がありません: ニュースグループCommentという名前: 新しいデータ・ブロックの始まり。 例: 以下を命名してください。 de.admin.news.announce
Status
状態
Header: Status
ヘッダー: 状態
Used for: hierarchy Mandatory: yes Inheritable: no Repeatable: no Description: Status of a hierarchy. Comment: For a detailed description, see Section 6.4. Example: Status: Hierarchy-Complete
以下に使用されました。 階層構造Mandatory: はいInheritable: Repeatableがありません: 記述がありません: 階層構造の状態。 コメント: 詳述に関しては、セクション6.4を見てください。 例: 状態: 階層構造完全です。
Used for: newsgroup Mandatory: yes Repeatable: no Description: Status of a newsgroup. Comment: For a detailed description, see Section 6.4. Example: Status: Group-Moderated
以下に使用されました。 ニュースグループMandatory: はいRepeatable: 記述がありません: ニュースグループの状態。 コメント: 詳述に関しては、セクション6.4を見てください。 例: 状態: グループによって加減されています。
Grau, et al. Experimental [Page 28] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[28ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Serial
シリーズ
Header: Serial
ヘッダー: シリーズ
Used for: hierarchy Mandatory: no Inheritable: no Repeatable: no Description: Timestamp for hierarchy data. Comment: For a detailed description, see Section 6.4. Example: Serial: 20020821102413
以下に使用されました。 階層構造Mandatory: Inheritableがありません: Repeatableがありません: 記述がありません: 階層構造データのためのタイムスタンプ。 コメント: 詳述に関しては、セクション6.4を見てください。 例: シリーズ: 20020821102413
Used for: newsgroup Mandatory: no Inheritable: no Repeatable: no Description: Timestamp for newsgroup data. Comment: For a detailed description, see Section 6.4. Example: Serial: 20020821102413
以下に使用されました。 ニュースグループMandatory: Inheritableがありません: Repeatableがありません: 記述がありません: ニュースグループデータのためのタイムスタンプ。 コメント: 詳述に関しては、セクション6.4を見てください。 例: シリーズ: 20020821102413
Group for followup
追跡には、分類してください。
Header: Followup
ヘッダー: 追跡
Used for: newsgroup
Mandatory: no
Repeatable: no
Description: Name of the newsgroup that will take the followup
postings of a moderated group.
Comment: The value can be used as default value for the
"Followup-To:" header on postings to a moderated group.
This value is only useful on groups that are moderated
(Status Group-Moderated) and have a dedicated discussion
group.
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: 記述がありません: 加減されたグループの追跡任命を取るニュースグループの名前。 コメント: 「Followup-To:」にデフォルト値として値を使用できます。 加減されたグループへの任命でのヘッダー。 この値は単に加減されて(状態はGroup加減されました)、専用ディスカッション・グループを持っているグループで役に立ちます。
Example: Followup: bln.announce.fub.zedat.d
(for the moderated group bln.announce.fub.zedat)
例: 追跡: bln.announce.fub.zedat.d(加減されたグループbln.announce.fub.zedatのための)
Grau, et al. Experimental [Page 29] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[29ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Short description
短い記述
Header: Description
ヘッダー: 記述
Used for: hierarchy
Mandatory: no
Inheritable: no
Repeatable: no
Description: Short description of a hierarchy.
Example: Description: Angelegenheiten, die den Grossraum Berlin
betreffen
(for the hierarchy bln)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: Repeatableがありません: 記述がありません: 階層構造の短い記述。 例: 記述: Angelegenheiten、穴のGrossraumベルリンbetreffenで、死んでください。(階層構造十億のための)
Used for: newsgroup
Mandatory: no
Repeatable: no
Description: Short description of a newsgroup.
Comment: This information is often presented to the news reader
upon selection of the newsgroup, and it should be a
brief but meaningful description of the topic.
Example: Description: Technisches zur Newssoftware
(for de.admin.news.software)
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: 記述がありません: ニュースグループの短い記述。 コメント: この情報はニュースグループの選択のときにしばしばニュース読者に提示されます、そして、それは話題の簡潔な、しかし、重要な記述であるべきです。 例: 記述: Technisches zur Newssoftware(de.admin.news.softwareのための)
Charter-URL
憲章URL
Header: Charter
ヘッダー: 憲章
Used for: hierarchy
Mandatory: no
Inheritable: no
Repeatable: yes
Description: URL that points to the charter of a hierarchy.
Example: Charter: ftp://ftp.fu-berlin.de.example/doc/news/bln/bln
(for the hierarchy bln)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: Repeatableがありません: はい記述: 階層構造の特許を示すURL。 例: 以下をチャーターしてください。 ftp://ftp.fu-berlin.de.example/doc/news/bln/bln (階層構造十億のための)
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: URL that points to the charter of a newsgroup.
Comment: This information should be presented to the
news reader upon selection of the newsgroup.
Example: Charter: ftp://ftp.fu-berlin.de.example/doc/news/bln
/bln.markt.arbeit
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: ニュースグループの特許を示すURL。 コメント: この情報はニュースグループの選択のときにニュース読者に提示されるべきです。 例: 以下をチャーターしてください。 ftp://ftp.fu-berlin.de.example/doc/news/bln /bln.markt.arbeit
Grau, et al. Experimental [Page 30] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[30ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Netiquette-URL
ネチケットURL
Header: Netiquette
ヘッダー: ネチケット
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: yes
Description: URL that points to the netiquette of a hierarchy.
Comment: Since the netiquettes are often valid for
a complete hierarchy, this is inheritable.
Example: Netiquette:
http://www.kirchwitz.de.example/~amk/dni/netiquette
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: 階層構造のネチケットを示すURL。 コメント: 完全な階層構造に、ネチケットがしばしば有効であるので、これは相続可能です。 例: ネチケット: http://www.kirchwitz.de.example/~amk/dni/netiquette
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: URL for Netiquette.
Comment: If a group has some special rules, this is the
pointer to these rules.
Example: Netiquette: http://go.to.example/bln.markt
(for bln.markt)
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: ネチケットのためのURL。 コメント: グループにいくつかの特別な規則があるなら、これはこれらの規則へのポインタです。 例: ネチケット: http://go.to.example/bln.markt (bln.marktのための)
Frequently Asked Questions (FAQ)
よく出る質問(FAQ)
Header: FAQ
ヘッダー: FAQ
Used for: Newsgroup Mandatory: no Repeatable: yes Description: URL for the FAQ of a newsgroup. Example: FAQ: http://www.dard.de.example/
以下に使用されました。 ニュースグループ義務的: Repeatableがありません: はい記述: ニュースグループのFAQのためのURL。 例: FAQ: http://www.dard.de.example/
Administration rules
政権規則
Header: Rules
ヘッダー: 規則
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: yes
Description: URL pointing to a document that describes the rules for
creating, deleting, or renaming newsgroups in this
hierarchy.
Comment: Normally inherited from the toplevel hierarchy.
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: この階層構造でニュースグループを創設するか、削除するか、または改名するための規則について説明するドキュメントを示すURL。 コメント: 通常、toplevel階層構造から引き継がれます。
Grau, et al. Experimental [Page 31] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[31ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Example: Rules: http://www.kirchwitz.de.example/~amk/dai
/einrichtung
例: 規則: http://www.kirchwitz.de.example/~amk/dai /einrichtung
Control Email
コントロールメール
Header: Ctl-Send-Adr
ヘッダー: CtlはAdrを送ります。
Used for: hierarchy Mandatory: no Inheritable: yes Repeatable: yes Description: Email address of the sender of control messages. Comment: Multiple addresses are valid. Example: Ctl-Send-Adr: group-admin@isc.org.example
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: コントロールメッセージの送付者のEメールアドレス。 コメント: 複数のアドレスが有効です。 例: CtlはAdrを送ります: group-admin@isc.org.example
Control newsgroup
コントロールニュースグループ
Header: Ctl-Newsgroup
ヘッダー: Ctl-ニュースグループ
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: yes
Description: Name of the newsgroup that will get the postings for
checkgroups, rmgroup, and newsgroup control messages.
Example: Ctl-Newsgroup: de.admin.news.groups
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: checkgroupsのために任命を得るニュースグループ、rmgroup、およびニュースグループコントロールメッセージの名前。 例: Ctl-Newsgroup: de.admin.news.groups
Moderators
議長
Header: Mod-Wildcard
ヘッダー: モッズワイルドカード
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: no
Description: Moderator wildcard for this hierarchy.
Comment: This information can be used for the configuration of
the news software, for example, to configure the
moderators file in INN.
Example: Mod-Wildcard: %s@moderators.dana.de.example
(for the hierarchy de)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: 記述がありません: この階層構造のための議長ワイルドカード。 コメント: 例えば、ニュースソフトウェアの構成がINNの議長ファイルを構成するのにこの情報を使用できます。 例: モッズ風のワイルドカード: %s@moderators.dana.de.example (階層構造deのための)
Grau, et al. Experimental [Page 32] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[32ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Submission address
服従アドレス
Header: Mod-Sub-Adr
ヘッダー: モッズサブAdr
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: Email address for submissions to the newsgroup.
Comment: If there is no "Mod-Sub-Adr" for a moderated newsgroup,
"Mod-Wildcard" of the hierarchy is used. This is useful
only for moderated groups (Status Group-Moderated).
Example: Mod-Sub-Adr: news-answers@mit.edu.example
(for the newsgroup news.answers)
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: ニュースグループへの差出のためのEメールアドレス。 コメント: 加減されたニュースグループの「モッズサブAdr」が全くなければ、階層構造の「モッズワイルドカード」は使用されています。 これは加減されたグループだけの役に立ちます(状態はGroup加減されました)。 例: モッズサブAdr: news-answers@mit.edu.example (ニュースグループnews.answersのための)
Moderator's address (email)
議長のアドレス(メール)
Header: Mod-Adm-Adr
ヘッダー: モッズ-Adm-Adr
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: Email address of the moderator of the newsgroup.
Comment: If there is no code "Mod-Adm-Adr" for a moderated
newsgroup, "Mod-Wildcard" of the hierarchy is used.
This is useful only for moderated groups
(Status Group-Moderated).
Example: Mod-Adm-Adr: news-answers-request@mit.edu.example
(for the newsgroup news.answers)
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: ニュースグループの議長のEメールアドレス。 コメント: 加減されたニュースグループのためのコード「モッズ-Adm-Adr」が全くなければ、階層構造の「モッズワイルドカード」は使用されています。 これは加減されたグループだけの役に立ちます(状態はGroup加減されました)。 例: モッズ風のAdm-Adr: news-answers-request@mit.edu.example (ニュースグループnews.answersのための)
Info-URL
インフォメーションURL
Header: Mod-Group-Info
ヘッダー: モッズグループインフォメーション
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: URL that points to a document where the moderator
presents information about the newsgroup and the
submission of articles.
Example: Mod-Group-Info: http://www.example.org/cola-submit.html
(for comp.os.linux.announce)
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: 議長がニュースグループと記事の提出に関して情報を提供するドキュメントを示すURL。 例: モッズグループインフォメーション: http://www.example.org/cola-submit.html (comp.os.linux.announceのための)
Grau, et al. Experimental [Page 33] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[33ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Language
言語
Header: Language
ヘッダー: 言語
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: yes
Description: The language that will normally be used in postings.
Comment: The notation is according to the "Content-Language"
field of [RFC2616]. The languages not
preferred are enclosed in parentheses.
Example: Language: DE
(for the hierarchy de)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: 通常、任命に使用される言語。 コメント: [RFC2616]の「満足している言語」分野に従って、記法があります。 好まれなかった言語は括弧に同封されます。 例: 言語: DE(階層構造deのための)
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: The language that will normally be used in postings.
Comment: The notation is according to the "Content-Language"
field of [RFC2616]. The languages not
preferred are enclosed in parentheses.
Example: Language: TR
Language: DE
Language: (EN)
(for the newsgroup bln.kultur.tuerkisch)
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: 通常、任命に使用される言語。 コメント: [RFC2616]の「満足している言語」分野に従って、記法があります。 好まれなかった言語は括弧に同封されます。 例: 言語: TR言語: DE言語: (アン) (ニュースグループbln.kultur.tuerkischのための)
Charset
Charset
Header: Charset
ヘッダー: Charset
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: yes
Description: Charset that will normally be used in postings in this
hierarchy.
Comment: The complete set of charset names is defined by
[RFC2277] and the IANA Character Set registry [IANA-CS].
The charsets that are not the preferred charsets are
enclosed in parentheses.
Example: Charset: ISO-8859-1
(for the hierarchy de)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: 通常、この階層構造に任命に使用されるCharset。 コメント: [RFC2277]とIANA文字コード登録[IANA-CS]によって完全なセットのcharset名は定義されます。 都合のよいcharsetsでないcharsetsは括弧に同封されます。 例: Charset: ISO-8859-1(階層構造deのための)
Grau, et al. Experimental [Page 34] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[34ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: Charset that will normally be used in
postings in this group.
Comment: The complete set of charset names is defined by
[RFC2277] and the IANA Character Set registry
[IANA-CS]. The charsets that are not the preferred
charsets are enclosed in parentheses.
Example: Charset: ISO-8859-9
Charset: ISO-8859-1
(for the newsgroup bln.kultur.tuerkisch)
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: 通常、これでの任命に使用されるCharsetは分類します。 コメント: [RFC2277]とIANA文字コード登録[IANA-CS]によって完全なセットのcharset名は定義されます。 都合のよいcharsetsでないcharsetsは括弧に同封されます。 例: Charset: ISO-8859-9 Charset: ISO-8859-1(ニュースグループbln.kultur.tuerkischのための)
Encoding
コード化
Header: Encoding
ヘッダー: コード化
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: yes
Description: Encoding for this hierarchy according to MIME [RFC2045].
Comment: This is the media type used in this hierarchy; a list of
registered media types can be found at [IANA-MT]. The
encodings not preferred are enclosed in parentheses.
Example: Encoding text/plain
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: この階層構造のために、MIMEによると、[RFC2045]をコード化します。 コメント: これはこの階層構造に使用されるメディアタイプです。 [IANA-MT]で登録されたメディアタイプのリストを見つけることができます。 好まれなかったencodingsは括弧に同封されます。 例: テキスト/平野をコード化します。
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: Encoding for this newsgroup according to MIME [RFC2045].
Comment This is the media type used in this newsgroup; a list of
registered media types can be found at [IANA-MT]. The
encodings not preferred are enclosed in parentheses.
Example: Encoding: text/plain
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: このニュースグループのために、MIMEによると、[RFC2045]をコード化します。 コメントThisはこのニュースグループに使用されるメディアタイプです。 [IANA-MT]で登録されたメディアタイプのリストを見つけることができます。 好まれなかったencodingsは括弧に同封されます。 例: コード化します: テキスト/平野
Grau, et al. Experimental [Page 35] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[35ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Type of newsgroup
ニュースグループのタイプ
Header: Newsgroup-Type
ヘッダー: ニュースグループ-タイプしてください。
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: yes
Description: Default newsgroup type in this hierarchy.
Comment: This header has no concrete meaning for a hierarchy but
is used for the inheritance to newsgroups in the
hierarchy.
Specification of the types can be found in Section 6.5.
Example: Newsgroup-Type: Discussion
(for the hierarchy de)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: この階層構造のデフォルトニュースグループタイプ。 コメント: このヘッダーは、階層構造のためにどんな具体的な意味も持っていませんが、遺産のために階層構造でニュースグループに慣れています。 セクション6.5でタイプの仕様を見つけることができます。 例: ニュースグループ-タイプしてください: 議論(階層構造deのための)
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: Type of newsgroup.
Comment: Specification of the types can be found in Section 6.5.
Example: Newsgroup-Type: Announce
(for de.admin.news.announce)
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: ニュースグループのタイプ。 コメント: セクション6.5でタイプの仕様を見つけることができます。 例: ニュースグループ-タイプしてください: 発表してください。(de.admin.news.announceのための)
Type of hierarchy
階層構造のタイプ
Header: Hier-Type
ヘッダー: Hier-タイプ
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: yes
Description: Type of hierarchy.
Comment: Specification of the types can be found in Section 6.6.
Example: Hier-Type: Regional
(for hierarchy bln)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: 階層構造のタイプ。 コメント: セクション6.6でタイプの仕様を見つけることができます。 例: Hier-タイプ: 地方(階層構造十億のための)
Grau, et al. Experimental [Page 36] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[36ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Regional or Organizational Area
地方の、または、組織的な領域
Header: Area
ヘッダー: 領域
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: yes
Description: Description of the geographical region or organization
of this hierarchy.
Comment: This code is useful when the hierarchy type
(Hier-Type) is "Regional" or "Organization".
Example: Area: Grossraum Berlin
(for the hierarchy bln)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: 地理的な領域の記述かこの階層構造の組織。 コメント: 階層構造タイプ(Hier-タイプ)が「地方」か「組織」であるときに、このコードは役に立ちます。 例: 領域: Grossraumベルリン(階層構造十億のための)
Name length of group names
グループ名の名前の長さ
Header: Name-Length
ヘッダー: 名前長さ
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: no
Description: Maximum length of a newsgroup name.
Example: Name-Length: 72
(for the hierarchy bln)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: 記述がありません: ニュースグループ名の最大の長さ。 例: 名前長さ: 72 (階層構造十億のための)
Component length of group names
グループ名のコンポーネントの長さ
Header: Comp-Length
ヘッダー: コンピュータ長さ
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: no
Description: Maximum length of a single component in the newsgroup
name.
Example: Comp-Length: 14
(for the hierarchy de)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: 記述がありません: ニュースグループ名のただ一つのコンポーネントの最大の長さ。 例: コンピュータ長さ: 14 (階層構造deのための)
Grau, et al. Experimental [Page 37] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[37ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Article length
記事の長さ
Header: Article-Length
ヘッダー: 記事長さ
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: no
Description: Maximum length of an article in bytes.
Comment: This header has no concrete meaning for a hierarchy but
is used for the inheritance to newsgroups in the
hierarchy.
Example: Article-Length: 50000
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: 記述がありません: バイトで表現される記事の最大の長さ。 コメント: このヘッダーは、階層構造のためにどんな具体的な意味も持っていませんが、遺産のために階層構造でニュースグループに慣れています。 例: 記事長さ: 50000
Used for: newsgroup Mandatory: no Repeatable: no Description: Maximum length of an article in bytes. Example: Article-Length: 50000
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: 記述がありません: バイトで表現される記事の最大の長さ。 例: 記事長さ: 50000
Date of creation
創造の日付
Header: Date-Create
ヘッダー: 日付で作成します。
Used for: hierarchy Mandatory: no Inheritable: yes Repeatable: no Description: Creation date of a hierarchy; can even be in the future. Comment: The format is the same as in the DATE command. Example: Date-Create: 19970330101514
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: 記述がありません: 階層構造の作成日付。 未来に、あることさえできます。 コメント: 形式はDATEコマンドと同じです。 例: 以下を日付で作成してください。 19970330101514
Used for: newsgroup Mandatory: no Repeatable: no Description: Creation date of a newsgroup; can even be in the future. Comment: The format is the same as in the DATE command. Example: Date-Create: 19970330101514
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: 記述がありません: ニュースグループの作成日付。 未来に、あることさえできます。 コメント: 形式はDATEコマンドと同じです。 例: 以下を日付で作成してください。 19970330101514
Grau, et al. Experimental [Page 38] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[38ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Date of removal
取り外しの日付
Header: Date-Delete
ヘッダー: 日付で削除します。
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: no
Description: Date of removal of a hierarchy; can even be in the
future.
Comment: The format is the same as in the DATE command.
Example: Date-Delete: 19970330101514
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: 記述がありません: 階層構造の取り外しの日付。 未来に、あることさえできます。 コメント: 形式はDATEコマンドと同じです。 例: 以下を日付で削除してください。 19970330101514
Used for: newsgroup
Mandatory: no
Repeatable: no
Description: Date of removal of a newsgroup; can even be in the
future.
Comment: The format is the same as in the DATE command.
Example: Date-Delete: 19970330101514
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: 記述がありません: ニュースグループの取り外しの日付。 未来に、あることさえできます。 コメント: 形式はDATEコマンドと同じです。 例: 以下を日付で削除してください。 19970330101514
Successor
後継者
Header: Replacement
ヘッダー: 交換
Used for: hierarchy
Mandatory: no
Inheritable: no
Repeatable: yes
Description: Name of the hierarchy that replaced a removed hierarchy
if status is "Hierarchy-Obsolete" or will replace a
hierarchy if the date of removal is in the future.
Example: Replacement: de
(for the hierarchy sub)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: Repeatableがありません: はい記述: 状態が「階層構造時代遅れである」、または取り外しの日付であるなら階層構造を置き換えるなら、未来に、取り除かれた階層構造を置き換えた階層構造の名前があります。 例: 交換: de(階層構造潜水艦のための)
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: Name of the newsgroup or newsgroups that will replace a
removed newsgroup if status is "Group-Removed" or will
replace the newsgroup if the date of removal is in the
future.
Example: Replacement: bln.markt.arbeit
(for bln.jobs)
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: 未来に、状態が「グループによって取り除かれる」か、または取り外しの日付であるならニュースグループに取って代わるなら取り除かれたニュースグループに取って代わるニュースグループかニュースグループの名前があります。 例: 交換: bln.markt.arbeit(bln.jobsのための)
Grau, et al. Experimental [Page 39] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[39ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Source
ソース
Header: Source
ヘッダー: ソース
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: no
Description: Pointer to an organization or person responsible
for this hierarchy. SHOULD be a URL or an email
address.
Example: Source: http://www.dana.de.example/mod/
(for the hierarchy de)
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: 記述がありません: この階層構造に責任がある組織か人へのポインタ。 SHOULD、URLかEメールアドレスになってください。 例: ソース: http://www.dana.de.example/mod/ (階層構造deのための)
E: This is for tracking the maintainer of a hierarchy.
E: これは、階層構造の維持装置を追跡するものです。
Control PGP key
制御PGPキー
Header: Ctl-PGP-Key
ヘッダー: Ctl-PGP主要です。
Used for: hierarchy
Mandatory: no
Inheritable: yes
Repeatable: yes
Description: PGP key (with additional information: key owner, key-id,
etc.) of the sender of control messages in this
hierarchy.
Comment: The exact format is described in Section 6.7.
Example: Ctl-PGP-Key:
U de.admin.news.announce
B 1024
I D3033C99
L http://www.dana.de.example/mod/pgp/dana.asc
L ftp://ftp.isc.org.example/pub/pgpcontrol/PGPKEYS.gz
F 5B B0 52 88 BF 55 19 4F 66 7D C2 AE 16 26 28 25
V 2.6.3ia
K------BEGIN PGP PUBLIC KEY BLOCK-----
K-Version: 2.6.3ia
K-
K-mQCNEALZ+Xfm/WDCEMXM48gK1PlKG6TkV3SLbXt4CnzpGM0tOMa
K-HjlHqM1wEGUHD5hw/BL/heR5Tq+C5IEyXQQmYwkrgeVFMOz/rAQ
[...]
K-SDw+iQgAAtN6zrYOhHFBp+
K-VpvRovMz+lSOy9Zcsbs+5t8Pj9ZVAQyfxBkqD5A=
K-=Xwgc
K -----END PGP PUBLIC KEY BLOCK-----
以下に使用されました。 階層構造Mandatory: Inheritableがありません: はいRepeatable: はい記述: この階層構造のコントロールメッセージの送付者のPGPキー(追加情報: 主要な所有者、主要なイドなどがある)。 コメント: 正確な形式はセクション6.7で説明されます。 例: Ctl-PGP-キー: U de.admin.news.announce B1024I D3033C99L http://www.dana.de.example/mod/pgp/dana.asc L ftp://ftp.isc.org.example/pub/pgpcontrol/PGPKEYS.gz F5B B0 52 88BF55 19 4F66 7D C2 AE16 26 28 25V2.6.3ia K------PGP公開鍵ブロックを始めてください。----- Kバージョン: 2.6.3 ia K K-mQCNEALZ+Xfm/WDCEMXM48gK1PlKG6TkV3SLbXt4CnzpGM0tOMa K-HjlHqM1wEGUHD5hw/BL/heR5Tq+C5IEyXQQmYwkrgeVFMOz/rAQ[…] K-VpvRovMz+lSOy9Zcsbs+5t8Pj9ZVAQyfxBkqD5A=K K-SDw+iQgAAtN6zrYOhHFBp+=Xwgc K-----端のPGP公開鍵ブロック-----
Grau, et al. Experimental [Page 40] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[40ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Moderator's PGP key
議長のPGPキー
Header: Mod-PGP-Key
ヘッダー: モッズPGPキー
Used for: newsgroup
Mandatory: no
Repeatable: yes
Description: Public PGP key (with additional information: key owner,
key-id, etc.) of this newsgroup's moderator.
Comment: The exact format is described in Section 6.7
Example: See Section 6.7.
以下に使用されました。 ニュースグループMandatory: Repeatableがありません: はい記述: このニュースグループの議長の公共のPGPキー(追加情報: 主要な所有者、主要なイドなどがある)。 コメント: 正確な形式はセクション6.7 Exampleで説明されます: セクション6.7を見てください。
6.4. Status Indicators
6.4. 自動運転表示灯
The status indicator uniquely determines the status of a hierarchy or newsgroup. The indicator is case insensitive.
自動運転表示灯は唯一階層構造かニュースグループの状態を決定します。 インディケータは大文字と小文字を区別しないです。
Indicator Type Description
----------- --------- -------------------------------------------
Complete hierarchy Authorized, complete known hierarchy
Incomplete hierarchy Not completely known hierarchy (like free.*)
Obsolete hierarchy Obsolete hierarchy; should contain only
newsgroups with status "Removed"
Unknown hierarchy No information available; unknown hierarchy
Unmoderated newsgroup Posting allowed; unmoderated
Readonly newsgroup Posting not allowed
Moderated newsgroup Moderated group; articles must be sent to
the moderator
Removed newsgroup Deleted or renamed newsgroup; no posting or
transport
Unknown newsgroup Unknown group; no information available
----------- --------- -------------------------------------------
インディケータ型記述----------- --------- ------------------------------------------- 階層構造Authorized、完全な知られている階層構造のNot完全に知られている階層構造(同類は. *を解放する)時代遅れの階層構造Obsolete Incomplete階層構造階層構造を完成してください。 状態の「取り除かれた」Unknown階層構造いいえ情報が利用可能のニュースグループだけを含むべきです。 Postingが許容した未知の階層構造Unmoderatedニュースグループ。 unmoderated ReadonlyニュースグループPostingはModeratedニュースグループModeratedグループを許容しませんでした。 記事を議長RemovedニュースグループDeletedに送らなければならないか、またはニュースグループに改名しなければなりません。 任命でない輸送UnknownニュースグループUnknownグループがありません。 利用可能な情報がありません。----------- --------- -------------------------------------------
6.5. Newsgroup Types
6.5. ニュースグループはタイプされます。
A Newsgroup Type is a comprehensive overview about some characteristics of a newsgroup, being a test group, a binary group, or some other kind. The Newsgroup Type is case insensitive.
ニュースグループTypeはニュースグループのいくつかの特性に関する包括的な概観です、テストグループ、2進のグループ、またはある他の種類であり。 ニュースグループTypeは大文字と小文字を区別しないです。
Type Meaning ----------- ------------------------------------------------------ Discussion Discussion (text postings) Binary (Encoded) binary postings Sources Source postings (e.g., comp.unix.sources) Announce Announcements, press releases, RfD/CfV Test Test postings, sometimes reflectors (e.g., de.test)
意味をタイプしてください。----------- ------------------------------------------------------ 議論Discussion(テキスト任命)バイナリー(コード化される)の2進の任命Sources Source任命(例えば、comp.unix.sources)はAnnouncements、プレスリリース、RfD/CfV Test Test任命、時々反射鏡を示します。(例えば、de.test)
Grau, et al. Experimental [Page 41] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[41ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Robots Automatic postings (like the former comp.mail.maps) Experiment Experimental, other ----------- ------------------------------------------------------
ロボットAutomatic任命(元comp.mail.mapsのような)実験Experimentalで、他です。----------- ------------------------------------------------------
6.6. Hierarchy Types
6.6. 階層構造タイプ
To describe a hierarchy, the following Hierarchy Types are used. These Types are used to mark some properties of a news hierarchy. They are case insensitive.
階層構造について説明するために、以下のHierarchy Typesは使用されています。 これらのTypesは、ニュース階層構造のいくつかの特性をマークするのに使用されます。 それらは大文字と小文字を区別しないです。
Type Meaning
-------------- ---------------------------------------------------
Global International, global hierarchy
(e.g., the hierarchies comp, de, rec)
Regional Regional hierarchy
(e.g., the hierarchies ba, bln, tor)
Alt Alternative hierarchy, simpler rules for
creating a group, no formal structure
(e.g., the hierarchy alt)
Non-commercial Only for personal use; commercial use is prohibited
(e.g., the hierarchy de)
Commercial Commercial use permitted (e.g., the hierarchy biz)
Organization Hierarchy bound to an organization
(e.g., the hierarchy gnu)
-------------- ---------------------------------------------------
意味をタイプしてください。-------------- --------------------------------------------------- グローバルなインターナショナルで、グローバルな階層構造(例えば、階層構造コンピュータ、de、rec)の地方のRegional階層構造(例えば、階層構造Ba、十億、tor)Alt Alternative階層構造、グループを創設するための、より簡単な規則、個人的な使用のためのホルマール構造がないこと(例えば、階層構造alt)の非営利的なOnly。 商業用途は組織(例えば、階層構造ヌー)に縛られた禁止された(例えば、階層構造de)商業Commercial認められる使用(例えば、階層構造ビジネス)組織Hierarchyです。-------------- ---------------------------------------------------
6.7. PGP Keys
6.7. PGPキー
PGP keys for Ctrl-PGP-Key and Mod-PGP-Key are transmitted in the following structure:
Ctrl-PGP-キーとMod-PGP-キーのためのPGPキーは以下の構造で送られます:
PGP-answer = "V" SP Version CRLF
"U" SP User-ID CRLF
"B" SP Bits CRLF
"I" SP Key-ID CRLF
"F" SP Finger CRLF
*("L" SP Location CRLF)
*("K-" Keyblock CRLF)
"K" SP Keyblock CRLF
PGP-答え=「V」SPバージョンCRLF「U」SPユーザID CRLF「B」SPビットCRLF「I」SP主要なID CRLF「F」SP指のCRLF*(「L」SP位置のCRLF)*(「K」Keyblock CRLF)「K」SP Keyblock CRLF
Version = text User-ID = text Bits = text Key-ID = text Finger = text Location = text Keyblock = text
バージョン=テキストUser-ID=テキストBitsはテキストFinger=テキストLocation=テキストKeyblock=テキストKey-ID=テキストと等しいです。
Grau, et al. Experimental [Page 42] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[42ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Key Name Mandatory Description
--- --------- --------- --------------------------------------
K Keyblock yes Public key block in ASCII armor format
[RFC2440]
V Version yes PGP-Version
U User-ID no Key user id
B Bits no Number of bits
I Key-ID no Key id, without leading "0x"
F Finger no Fingerprint
L Location no URL that points to the public key
--- --------- --------- --------------------------------------
主要な名前義務的な記述--- --------- --------- -------------------------------------- K KeyblockはいPublicキーはビットIのASCIIよろいかぶと形式[RFC2440]VバージョンはいPGP-バージョンU User-IDノーKeyユーザイドB BitsノーNumber Key-IDでKeyイドを全く妨げないで、また主な"0x"F FingerのないどんなFingerprint L Locationも公開鍵を示すURLではありません。--- --------- --------- --------------------------------------
A hyphen following the code indicates that the block is continued on the next line. In the last message row, there MUST be white space after the code; this is also true for a single line code.
コードに従うハイフンは、ブロックが次の系列で続けられているのを示します。 最後のメッセージ行には、コードの後に、余白があるに違いありません。 また、単線コードに、これも本当です。
Example
例
<-- HIER de
--> 611 Data coming
Name: de
Status: Hierarchy
[...]
Ctl-PGP-Key:
U de.admin.news.announce
B 1024
I D3033C99
L http://www.dana.de.example/mod/pgp/dana.asc
L ftp://ftp.fu-berlin.de.example/unix/news/pgpcontrol/PGPKEYS.gz
F 5B B0 52 88 BF 55 19 4F 66 7D C2 AE 16 26 28 25
V 2.6.3ia
K------BEGIN PGP PUBLIC KEY BLOCK-----
K-Version: 2.6.3ia
K-
K-mQCNAzGeB/YAAAEEALZ+Xfm/WDCEMXM48gK1PlKG6TkV3SLbXt4CnzpGMtOM
K-HjlHaU6Xco5ijAuqM1wEGUHD5hw/BL/heR5Tq+C5IEyXQQmYwkrgeVFMO/rA
[...]
K-SDw+Id0JPFO9AWOiQgAAtN6zrYOhHFBp+68h9k674Yg9IHqj3BWdRjJF6PKo
K-VpvRovMz+lSOy9Zcsbs+5t8Pj9ZVAQyfxBkqD5A=
K-=Xwgc
K -----END PGP PUBLIC KEY BLOCK-----
[...]
<--HIER de-->の611のDataの次のName: de Status: 階層構造[…] Ctl-PGP-キー: U de.admin.news.announce B1024I D3033C99L http://www.dana.de.example/mod/pgp/dana.asc L ftp://ftp.fu-berlin.de.example/unix/news/pgpcontrol/PGPKEYS.gz F5B B0 52 88BF55 19 4F66 7D C2 AE16 26 28 25V2.6.3ia K------PGP公開鍵ブロックを始めてください。----- Kバージョン: 2.6.3 ia K K-mQCNAzGeB/YAAAEEALZ+Xfm/WDCEMXM48gK1PlKG6TkV3SLbXt4CnzpGMtOM K-HjlHaU6Xco5ijAuqM1wEGUHD5hw/BL/heR5Tq+C5IEyXQQmYwkrgeVFMO/rA[…] K-SDw+Id0JPFO9AWOiQgAAtN6zrYOhHFBp+68h9k674Yg9IHqj3BWdRjJF6PKo K-VpvRovMz+lSOy9Zcsbs+5t8Pj9ZVAQyfxBkqD5AはK=Xwgc Kと等しいです。-----端のPGP公開鍵ブロック----- [...]
.
.
Grau, et al. Experimental [Page 43] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[43ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
7. Specification of the NAS Protocol (UDP)
7. NASプロトコルの仕様(UDP)
UDP is intended for reading programs (news readers); it is not in the scope of this document. The use of UDP for NAS will be described in a separate paper.
UDPは読み込みプログラム(ニュース読者)のために意図します。 それはこのドキュメントの範囲にありません。 UDPのNASの使用は別々の紙で説明されるでしょう。
8. IANA Considerations
8. IANA問題
The IANA has registered the application/nasdata media type as defined by the following information:
IANAは以下の情報によって定義されるようにアプリケーション/nasdataメディアタイプを示しました:
Media type name: application Media subtype name: nasdata Required parameters: none Optional parameters: level
メディア型名: アプリケーションメディア「副-タイプ」は以下を命名します。 nasdata Requiredパラメタ: なにも、Optionalパラメタ: レベル
The NAS protocol level number for the enclosed
NAS data package. If not present, the
protocol level defaults to 1.
NASは同封のNASデータパッケージのためにレベル番号について議定書の中で述べます。 プレゼントでないなら、プロトコルレベルは1をデフォルトとします。
Encoding scheme: NAS data is plain text; no special encodings are needed.
コード化体系: NASデータはプレーンテキストです。 どんな特別なencodingsも必要ではありません。
Security considerations: see below
セキュリティ問題: 以下を見てください。
9. Security Considerations
9. セキュリティ問題
Security issues are only addressed in respect to server-server communication in this protocol level. Username and password combinations in the GETA and GETP commands can be used to make sure that connections are only accepted from authorized clients. PGP keys according to [RFC2440] are used to sign NAS data in server-server communication in order to validate that the data is authentic and has not been tampered with.
安全保障問題はこのプロトコルレベルのサーバサーバコミュニケーションに関して扱われるだけです。 接続が認可されたクライアントから受け入れられるだけであるのを確実にするのにGETAとGETPコマンドにおけるユーザ名とパスワード組み合わせを使用できます。 [RFC2440]に従ったPGPキーによるそれを有効にして、NASがサーバサーバコミュニケーションのデータであると署名するのに使用されて、データが正統であり、いじられていないということです。
Every server does have the possibility (in both server-server and server-client communication) to deny some commands or the whole connection according to the client's IP number.
あらゆるサーバには、クライアントのIP番号によると、いくつかのコマンドか全体の接続を否定する可能性(サーバサーバとサーバクライアントコミュニケーションの両方の)があります。
No mechanisms are defined in the current protocol level to allow a client to validate that it is talking to a legitimate server or that the data it receives is authentic.
メカニズムは、全く有効にするそれが正統のサーバと話しているクライアントであって、それが受け取るデータが正統であることを許容するために現在のプロトコルレベルで定義されません。
A stronger authentication scheme will be provided in a higher protocol level.
より強い認証体系をより高いプロトコルレベルに提供するでしょう。
Grau, et al. Experimental [Page 44] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[44ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
10. Response Codes (Overview)
10. 応答コード(概要)
Code Description ---- -------------------------------------------------------------- 100 Command overview, Information, command description (HELP) 101 Information about connection, client and server (INFO) 200 Greeting message (Connection Setup) 201 Termination of the connection (QUIT) 202 Returns current protocol level (VERS) 213 Valid data at the client side (GETP) 215 The client already has the current data (GETA) 300 Time in UTC (DATE) 302 Answer to a successful request (VERS) 400 Indicates that the server is not giving any information (INFO) 401 Permission denied (LIST, LSTR, HIER, DATA) 402 Requested level too high; falling back to lower level (VERS) 404 Server currently out of service (Connection Setup) 410 Indicates that the server is not giving any information (HELP) 411 No hierarchy with that name (GETP, GETA) 430 Permission denied (GETP, GETA) 434 Client has no permission to talk to server (Connection Setup) 510 Syntax error 511 Internal error (TIME) 513 Line too long 519 Unknown command 610 Regular answer with all requested data (LIST, LSTR) 611 Regular answer with all requested data (HIER) 612 Regular answer with all requested data (DATA) 613 hierarchy data (GETP) 615 Regular answer with all requested data (GETA) ---- --------------------------------------------------------------
コード記述---- -------------------------------------------------------------- 100コマンド概要、情報は接続に関する記述(ヘルプ)101情報を命令します; クライアントの213の接続(QUIT)202Returnsの現在のプロトコルレベル(VERS)Validデータの(接続Setup)201Terminationはクライアントの(GETP)215に面があるというクライアントとサーバ(INFO)200Greetingメッセージで、サーバが(INFO)401Permissionが402Requestedレベルを否定した(LIST、LSTR、HIER、DATA)少しの情報も教えていないうまくいっている要求(VERS)400IndicatesへのUTC(DATE)302Answerの現在のデータ(GETA)300Timeは既に高くなり過ぎます。 現在使われなくなっていた状態で平らな(VERS)404Serverを下ろすために後ろへ下がって、サーバがどんな情報(ヘルプ)411いいえ階層構造も434Clientが否定される(GETP、GETA)その名前(GETP、GETA)430Permissionで与えていない(接続Setup)410Indicatesはサーバ(接続Setup)510と話す許可を全く持っていません; 長過ぎる519Unknownコマンド610Regularがすべてで答える構文エラー511Internal誤り(タイム誌)513線は、すべてがあるデータ(LIST、LSTR)611Regular答えが、(HIER)612Regularがすべてで答えるデータが、すべてがあるデータ(DATA)613階層構造データ(GETP)615Regular答えがデータ(GETA)を要求するよう要求するよう要求したよう要求しました。---- --------------------------------------------------------------
11. Data Headers for DATA and HIER Commands (Overview)
11. データのためのデータヘッダーとHIERコマンド(概要)
Header Mandatory Use Multiple Description
------------- --------- --- -------- ---------------------
Name yes H/N no Name of a hierarchy
or newsgroup (Start
of a new data block)
Status yes H/N no Status of hierarchy
or newsgroup
Serial no H/N no Revision of hierarchy
/newsgroup data
Followup no N no Group for followup
Description no H/N no Short description of
a hierarchy/newsgroup
Charter no H/N yes Charter-URL
Netiquette no H/N yes Netiquette-URL
ヘッダーの義務的な使用複数の記述------------- --------- --- -------- --------------------- Name yes H/N no Name of a hierarchy or newsgroup (Start of a new data block) Status yes H/N no Status of hierarchy or newsgroup Serial no H/N no Revision of hierarchy /newsgroup data Followup no N no Group for followup Description no H/N no Short description of a hierarchy/newsgroup Charter no H/N yes Charter-URL Netiquette no H/N yes Netiquette-URL
Grau, et al. Experimental [Page 45] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[45ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
FAQ no N yes FAQ-URL
Rules no H yes Administration rules
URL
Ctl-Send-Adr no H yes Control email
Ctl-Newsgroup no H yes Control newsgroup
Mod-Wildcard no H no Moderator wildcard
Mod-Sub-Adr no N no Submission address
Mod-Adm-Adr no N yes Moderator's address
(email)
Mod-Group-Info no N yes Info-URL
Language no H/N yes Language
Charset no H/N yes Charset
Encoding no H/N yes Encoding
Newsgroup-Type no H/N yes Type of newsgroup
Hier-Type no H yes Type of hierarchy
Area no H yes Regional or
organizational area
Name-Length no H no Total length of group
names
Comp-Length no H no Component length of
group names
Article-Length no H no Article length
Date-Create no H/N no Date of creation
Date-Delete no H/N no Date of removal
Replacement no H/N yes Successor
Source no H yes Source of data
Ctl-PGP-Key no H yes Control PGP key
Mod-PGP-Key no N yes Moderator's PGP key
------------- --------- --- -------- ---------------------
HはいのCtlがAdrを送っているどんなHはい政権も統治しないNはいFAQ URLがないRulesのFAQ URLノーControlはNはいのHはいControlニュースグループMod-ワイルドカードノーないH NノーないSubmissionが扱うModeratorワイルドカードがないModサブAdr Mod-Adm-AdrノーModeratorのCtl-ニュースグループアドレス(メール)モッズグループインフォメーションNはいInfo-URLがないLanguageにニュースグループHier-タイプのH/NはいのH/NはいのH/NはいLanguage CharsetノーないCharset Encoding NはいEncodingニュースグループH/タイプがないノーTypeをメールします; HはいがないことのType、Totalの長さのComponentの長さの階層構造のAreaのHはいがないことのRegionalの、または、組織的な部門Name-長さのノーHノーグループ名Comp-長さのノーHノーグループ名Article-長さのノーHノーArticle、長さがDate作成する、作成のH/NノーないDateがH/NノーないDateをDate削除する、取り外しReplacementでは、データのHはいのH/NはいSuccessor SourceノーないSourceはNはいがないことのModeratorのPGPが合わせるどんなHはいのControl PGPの主要なMod-PGP-キーもCtl-PGP合わせません。------------- --------- --- -------- ---------------------
N: Newsgroup, H: Hierarchy
N: ニュースグループ、H: 階層構造
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[IANA-CS] IANA: Character Sets,
<http://www.iana.org/assignments/character-sets>.
[IANA-Cs]IANA: 文字コード、<http://www.iana.org/課題/文字集合>。
[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月。
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
Grau, et al. Experimental [Page 46] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[46ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440] カラスとJ.とDonnerhackeとL.とフィニー、H.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年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月。」
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
12.2. Informative References
12.2. 有益な参照
[IANA-MT] IANA: Media Types, <http://www.iana.org/assignments/>.
[IANA-MT]IANA: メディアタイプ、<http://www.iana.org/assignments/>。
[IANA-PN] IANA: Assigned Port Numbers,
<http://www.iana.org/assignments/port-numbers>.
[IANA-PN]IANA: 割り当てられたポートナンバー、<http://www.iana.org/課題/ポートナンバー>。
[RFC1305] Mills, D., "Network Time Protocol", RFC 1305, University of
Delaware, March 1992.
[RFC1305] 工場、D.、「ネットワーク時間プロトコル」、RFC1305、デラウエア大学、1992年3月。
[SON1036] H. Spencer, "News Article Format and Transmission", A Draft
for an RFC 1036 Successor,
<ftp://zoo.toronto.edu/pub/news.txt.Z>.
Aは、1036年のRFC後継者、<ftp://zoo.toronto.edu/パブ/news.txt.Z>のために[SON1036]H.スペンサーと、「ニュース記事形式とトランスミッション」と作成します。
[USEFOR] USEFOR Working Group, "News Article Format", Work in
Progress.
[USEFOR]USEFOR作業部会、「ニュース記事形式」は進行中で働いています。
Acknowledgement
承認
This work has been supported by the German Academic Network Organization (DFN-Verein) with funds from the German Federal Ministry of Education and Research (Bundesministerium fuer Bildung und Forschung).
この仕事は基金でドイツのAcademic Network Organization(DFN-連盟)によってドイツの連邦政府の文部省とResearch(Bundesministerium fuer Bildung und Forschung)からサポートされました。
Grau, et al. Experimental [Page 47] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[47ページ]RFC4707ネットニュース行政システム(NAS)2006年10月
Authors' Addresses
作者のアドレス
Philipp Grau Vera Heinau Heiko Schlichting Robert Schuettler
フィリップ・グラウ・ヴェラ・Heinau Heiko Schlichtingロバート・シュトラー
Freie Universitaet Berlin ZEDAT Fabeckstr. 32 14195 Berlin Germany
Freie UniversitaetベルリンZEDAT Fabeckstr。 32 14195ベルリンドイツ
Phone: +49 30 838-74707 Fax: +49 30 838-56721
以下に電話をしてください。 +49 30 838-74707Fax: +49 30 838-56721
EMail: nas@fu-berlin.de URL: http://nas.fu-berlin.de/
メール: nas@fu-berlin.de URL: http://nas.fu-berlin.de/
Grau, et al. Experimental [Page 48] RFC 4707 Netnews Administration System (NAS) October 2006
グラウ、他 実験的な[48ページ]RFC4707ネットニュース行政システム(NAS)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 at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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)によって提供されます。
Grau, et al. Experimental [Page 49]
グラウ、他 実験的[49ページ]
一覧
スポンサーリンク
