Network Working Group P. Grau
Request for Comments: 4707 V. Heinau
Category: Experimental H. Schlichting
R. Schuettler
Freie Universitaet Berlin
October 2006
Netnews Administration System (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).
著作権（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は、いかなる目的のために、このRFCのフィットネスの知識を否認し、特にノートに公開するという決定は、セキュリティ、輻輳制御または展開されたプロトコルとの不適切な相互作用のようなもののためにIETFレビューに基づいていないこと。 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.
ネットニュース管理システム（NAS）は、インターネット上で（もネットニュースとして知られている）ネットワークニュースの管理と使用を簡素化するためのフレームワークです。ニュースグループや階層の管理のためのデータは、分散階層型データベースに保存し、クライアント・サーバ・プロトコルを介して利用できます。
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サーバから特定の情報を取得することができます。
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は、階層型データベースにユーズネットの幾分カオス構造を反映することができます。 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
12. References ....................................................46
12.1. Normative References .....................................46
12.2. Informative References ...................................47
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.
維持、増殖、および必要な情報を提供するのに役立ちますアウトオブバンドシステムを提供するネットニュースの管理システム（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.
クライアントがサーバに接続し、サーバが認証を要求することに起因し、これは、制御メッセージのためのものよりも情報を伝達するための、より合理的な手順です。
Furthermore, it is possible to check for changes on a regular basis at customized intervals to keep local data up-to-date.
また、最新ローカルデータを保持するためにカスタマイズされた間隔で定期的に変更を確認することが可能です。
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（Lightweight Directory Access Protocol）の、またはネットワーク情報サービス（NIS）などのディレクトリサービスに匹敵します。 NASプロトコルは、NNTPやSMTPなどのプロトコルに触発されています。ポート991は、NAS用に予約され、インターネット割り当て番号機関（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システム、のような構造を確立することが可能である、そしてどこいくつかはよく維持されていません。目標は、1つの帽子の下で可能な限り多くの情報を得ることですが、これを達成するために何の「公式」力があることはできません。
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、デ。*、私たち。*、BLN。*、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.
しかし、また、いくつかのNASサーバは、ALTにいくつかのデータ提供。*、さらにいくつか提供ALT。* ALT。！、例えば、上のバイナリデータを提供する特別なポリシーまたはルールのセットを以下の持っていることが想像されます。
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サーバを使用するように選択することができます。
.............. .............. ...................
. NAS server. . NAS server. . NAS server .
. . . . . alt.*, .
. alt.* . . Big8 . . !alt.binaries.*.
.............. .............. ...................
. database . . database . . database .
.............. .............. ...................
^ ^ ^ ^
`--+ +--' `------+ +----'
| | | |
.------------. .------------.
| NAS client | | NAS client |
+------------+ +------------+
| netnews | | netnews |
| server | | server |
.------------. .------------.
Configuration A Configuration B
設定Aの設定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はニュースグループや完全な階層に関する情報が含まれています。さらに、それは、単一のニュースグループのための階層継承エントリとデフォルト値に関する情報が含まれています。
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の実際の使用はネットニュース管理システムの要件を変更することが期待されます。一方、プロトコルは、改善を実現するために拡張可能で柔軟でなければなりません。一方で、それは異なるバージョン間の互換性を確保する必要があります。新しいプロトコルバージョンに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 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.
より高いプロトコルレベルの実装では、これは機能の損失を意味しても、低いレベルの挙動をエミュレートすることができなければなりません。クライアントとサーバとの間のプロトコルレベルのネゴシエーションがコマンドVERSの明細書に記載されています。プロトコルレベルでの合意がない場合、プロトコルレベル1のコマンドだけを使用しなければなりません。 NASの標準を増強または修正するドキュメントは、これらの変更が行われ、どのように行動が他のプロトコルレベルであるべきレベルに指定しなければなりません。
This document describes protocol level 1.
この文書では、プロトコルレベル1を説明します。
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サーバから収集した情報を提供しています。
............ 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 |
.---------.
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サーバへのリクエストは、いくつかのステップで達成されます。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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.
元のテキストは、テキスト行の最初の文字としてピリオドが含まれている場合は、その最初の期間が2倍になります。そのため、クライアントは、受信した各ラインの最初の文字を検討しなければならないと、ピリオドで始まるそれらのために、これはテキストの最後であるか、それは単一のものに倍増期間を折りたたむ必要があることをことのいずれかを決定します。
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の情報がサーバーに従いますnas.example.org（192.0.2.100）稼働時間：2週間、3日、5時間、9分のソフトウェア：NAS 1.0クライアント：client.example.org（192.0.2.123 ）接続：9分最上位のプロトコルレベルがサポートされている：1要求されたプロトコルレベル：使用される1プロトコルレベル：1。
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リクエスト成功3xxの要求、データが受け入れられたの4xx要求に従いますが、無操作可能
5xx Request is wrong (syntax error), is not implemented, or leads to an internal error 6xx Request successful, data follow until end mark
5xxの要求は、データがエンドマークまで続く、（構文エラー）間違って実装されていない、または内部エラーの6xx要求の成功を導き
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クエリ、回答、またはデータX2Xサーバー - サーバー通信x3x認証、承認x8x非標準の拡張機能は、出力をデバッグx9x
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行よりも長くなることがあります。
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は、典型的には、IANA [IANA-PN]によって予約されたポート991を使用します。接続がクライアントによって設定されている場合、サーバーはコード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.
クライアントがサーバーにアクセスする権限を持っていないため、接続が拒否された場合は、回答コードは決定は、クライアントのIPアドレスに基づいて、接続開始時に行うことができること434です。サーバがサービスの外に現在ある場合には、回答コードは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メッセージを送信した後、接続が閉じられます。
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サーバに送信されたオクテットがが付いています。ダイアログの方向が変化しない場合はインジケータが省略されています。
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.
以下に説明するコマンドは、[RFC4234]で定義された拡張バッカス・ナウアフォーム（ABNF）を使用して定義されています。 「ALPHA」、「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コマンドのセットを構成します。
Some overall definitions follow:
いくつかの全体的な定義は、次のとおりです。
text = %d1-9 / ; all octets except %d11-12 / ; US-ASCII NUL, CR and LF %d14-255
テキスト=％d1-9 /。 ％d11-12 /以外のすべてのオクテット。 US-ASCII NUL、CRとLF％d14-255
answertext = WSP *( ALPHA / DIGIT / "+" / "-" / "/" / "_" / "." / "," / ":" / "=" / "?" / "!" / SP )
answertext = WSP *（ALPHA / DIGIT / "+" / " - " / "/" / "_" / / "" / ""： "？" "！" "" / "=" / / / 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桁の数字
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）と同じにすることができるので、両者の間に違いはありません。
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 *（小文字/ DIGIT / "+" / " - " / "/" / "_" /「= ？ "/ ""）、プレーン成分=成分スタート*成分-残りの成分スタート=小文字/ DIGIT小文字=％x61-7A。レターZ小文字成分レスト=成分スタート/「+」/「 - 」/「_」
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の上位プロトコルレベルに統合されるべきです。
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 = "HELP" [WSPコマンド名] CRLF
commandname = "DATA" / "DATE" / "GETP" / "GETA" / "HELP" / "HIER" / "INFO" / "LIST" / "LSTR" / "QUIT" / "VERS"
コマンド名= "DATA" / "DATE" / "GETP" / "GETA" / "HELP" / "HIER" / "INFO" / "LIST" / "LSTR" / "QUIT" / "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
< - HELP
--> 100 NAS server nas.example.org - Version 1.0
- > 100 NASサーバ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
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 .
< - ヘルプリスト - > 100 LISTのLIST - リストのニュースグループや階層構文：LIST階層が...直接パラメータ階層の下のニュースグループやサブ階層のリストを取得します。
<-- HELP NOOP --> 410 unknown command "NOOP" .
< - HELP NOOP - > 410不明なコマンド "NOOP"。
Description
説明
Prints information about the current connection, the server, and the client.
現在の接続、サーバー、およびクライアントに関する情報を出力します。
info-cmd = "INFO" CRLF
情報-CMD = "INFO" CRLF
Possible answers
可能な答え
101: Normal answer; prints some information about client and server
101：通常の答え。クライアントとサーバーに関するいくつかの情報を出力します
400: Indicates that the server is not giving any information info-answer = "400" [answertext] CRLF text CRLF "." CRLF info-answer =/ "101" [answertext] CRLF text CRLF "." CRLF
400：サーバは任意の情報info-答え= "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の情報がサーバーに従いますnas.example.org（192.0.2.100）稼働時間：2週間、3日、5時間、9分のソフトウェア：NAS 1.0クライアント：client.example.org（192.0.2.123 ）接続：9分最上位のプロトコルレベルがサポートされている：1要求されたプロトコルレベル：使用される1プロトコルレベル：1
End
.
<-- INFO --> 400 No information available. .
< - INFO - > 400情報なし。 。
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でサーバ（協定世界時）の現在の時刻。 DATEコマンドは、情報提供のみを使用するため、サーバーの時刻を確認することです。ネットワーク上での時間を定期的に送信するために、ネットワークタイムプロトコル（NTP）[RFC1305]は使用すべきです。
date-cmd = "DATE" CRLF
日付-CMD = "DATE" 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
date-answer =/ "300" [answertext] CRLF utc-time [answertext] CRLF "." CRLF
日付の答え= / "300" [answertext] CRLFのUTC時刻[answertext] CRLF "" CRLF
Examples
例
<-- DATE --> 300 19990427135230 UTC .
< - DATE - > 300 19990427135230 UTC。
<-- DATE --> 511 Time is unknown .
< - DATE - > 511時間が不明です。
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 [プロトコルレベル]）によってセッション中にプロトコル・レベルを変更するために、めったに必要可能であるが、。 noオプションを指定しない場合、現在のプロトコルレベルが印刷されます。いかなるプロトコルレベルがネゴシエートされていない場合、プロトコルレベル1が使用されます。より高いレベルのコマンドは、成功した交渉なしで許可されていません。プロトコルレベルは、オプションのコメントが続くことができます。
vers-cmd = "VERS" [WSP level] CRLF
VERS-CMD = "VERS" [WSPレベル] CRLF
level = 1*5DIGIT ; the valid range is 1 - 32767
レベル= 1 * 5DIGIT。 32767 - 有効範囲は1です
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
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 2現在のプロトコルレベルが2です。
<-- VERS 2 --> 302 2 My max protocol level is 10 .
< - VERS 2 - > 302 2マイ最大プロトコルレベルは10です。
<-- VERS 11 --> 402 10 Falling back to level 10 .
< - VERS 11 - > 402 10はレベル10に戻って落ちます。
<-- VERS BAL --> 510 1 Syntax error .
< - VERS BAL - > 510 1構文エラー。
Description
説明
Terminates the connection.
接続を終了します。
quit-cmd = "QUIT" CRLF
終了-CMD = CRLFを "QUIT"
Possible answers
可能な答え
201: Termination of the connection
201：接続の終了
quit-answer = "201" [answertext] CRLF
終了回答= "201" [answertext] CRLF
Example
例
<-- QUIT --> 201 Closing connection. Bye.
< - QUIT - > 201クロージング接続。さようなら。
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.
要求された階層のニュースグループやサブ階層のリストを取得するには、コマンドリストが使用されています。階層の地位も与えられています。最高レベルは、すべてのトップレベルの階層で構成され、「*」と表示されています。それはあまりにも、この方法を得ることができます。
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.
データは行ごとnewsgroup-または階層名/ステータスインジケータの対から成ります。名前とステータスインジケータは、少なくとも一つの空白で区切る必要があります。ステータスインジケータは、単一の単語（6.4節を参照）です。解釈は大文字と小文字を区別しません。
list-cmd = "LIST" ( WSP "*" / 1*(WSP name)) CRLF
リスト-CMD = "LIST"（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
（CRLFたlistData）リスト-答えは= "610" [answertext] 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" /
リストステータス=「コンプリート」/「不完全」/「廃止」/「不明」/「モデレートなし」/「読み取り専用」/
"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不完全COMP完全デ不完全REC完全なサブ廃止に従います。
<-- 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デ - > 610件のデータが完全de.alt不完全de.comm完全de.comp完全de.etc完全de.markt完全de.newusers完全de.org完全de.rec完全de.sci de.admin従います議論が管理されていないde.test司会コンプリートde.socコンプリートde.answers。
<-- LIST foo --> 610 data follow foo Unknown .
< - LIST fooの - > 610のデータは、fooが不明従ってください。
<-- LIST --> 510 Syntax error missing parameter hierarchy .
< - LIST - > 510構文エラーパラメータの階層を逃します。
<-- LIST de --> 401 Something is wrong Permission denied .
< - LISTのデ - > 401何かが間違って許可が拒否されました。
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".
階層名の先頭に次のワイルドカードパターンとして「*」を使用することも可能です。その「LSTRのde.a *」は「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回答（CRLFたlistData）= "610" [answertext] 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
リストステータス=「コンプリート」/「不完全」/「廃止」/「不明」/「モデレートなし」/「読み取り専用」/「モデレート」/「削除」;リストステータスは大文字と小文字を区別しません
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コンプリートde.admin.infos司会de.admin.lists司会de.admin.misc議論が管理されていないde.admin.net-乱用完全de.admin.net、虐待.announceモデレートde.admin.net-abuse.mail議論が管理されていないde.admin.net-abuse.misc議論が管理されていないde.admin.net-abuse.news議論が管理されていないde.admin.newsコンプリートde.admin.news.announceモデレートde.admin .news.groups議論が管理されていないde.admin.news.misc議論が管理されていないde.admin.news.nocem議論が管理されていないde.admin.news.regeln議論が管理されていません。
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コマンドのオプションとして、要求されたヘッダーフィールドを返します。
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
選択= *（ "" ヘッダ）。データフィールドを説明します。ヘッダ= ALPHA *（ " - " ALPHA /）が要求されます。セクション6.3.4によると、
Example for selection
選択の例
,Followup,Description : For all entries list Name, Status, Followup and Description
、フォローアップ、説明：すべてのエントリのリスト名前について、ステータス、フォローアップと説明
Possible answers
可能な答え
401: Permission denied
401：アクセスが拒否されました
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キー：" CRLF PGP-答え/ "モッド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のデ - > 611データくる名：デ・ステータス：完全なシリアル：20020823120306説明：国際deutschsprachige Newsgruppenネチケットます：http：//www.kirchwitz.de.example/~amk/dni/netiquetteのFAQ：のhttp：/ /www.kirchwitz.de.example/~amk/dai/einrichtung CTL-送る-ADR：moderator@dana.de.example CTL-ニュースグループ：%s@moderators.dana：モッドワイルドカードde.admin.news.announce。 de.example言語：DE文字セット：ISO-8859-1エンコーディング：text / plainのニュースグループタイプ：ディスカッションハイアータイプ：グローバルコンプ-長さ：14日-作成：19920106000000
.
。
<-- HIER bln --> 401 Permission denied .
< - HIERのBLN - > 401権限が拒否されました。
<-- HIER --> 510 Syntax error missing parameter hierarchy .
< - HIER - > 510構文エラーパラメータの階層を逃します。
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コマンドは6.3.3.8で説明したように、HIERコマンドに対応するが、それは、ニュースグループについての情報のために使用されます。コードの概要は、セクション6.3.4に記載されています。
data-cmd = "DATA" 1*(WSP name) [WSP selection] CRLF
データCMD = "DATA" 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キー：" CRLF PGP-答え/ "モッド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
de.comp.os.unix.linux.moderatedステータス：：< - - DATA de.comp.os.unix.linux.moderated> 612のデータは、名前に続くシリアル司会：20020823120312説明：Linuxのウント-Distributionenを。 <dcoulm-moderators@linux-config.de.example>チャーターます：http：ネチケット//www.dana.de.example/mod/chartas/de.htmlます。http：//www.kirchwitz.de.example/~amk / DNI /ネチケット
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
.
。
<-- DATA de.foo --> 612 data follow Name: de.foo Status: Unknown
< - データde.foo - > 612データが名前に従います。de.fooステータス：不明
.
。
<-- DATA de --> 401 Permission denied .
< - データDe - > 401権限が拒否されました。
<-- DATA --> 510 Syntax error missing parameter newsgroup .
< - DATA - > 510構文エラー欠落しているパラメータのニュースグループ。
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」および「LIST」と同じです。 「*」階層名として指定されている場合は、サーバが提供している全てのデータが送信されます。
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」の場合は、サーバーがデータを送信することを余儀なくされます。
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].
成功した要求のデータが署名され、ASCII装甲に送ら[RFC2440]に記載ので、クライアントは、署名を確認するか、それを無視することができるされています。実際のデータは、[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（CHAR）/ "0"; VARCHARの長さ> = 1
password = *1( VCHAR ) / "0" ; Length of VCHAR >= 1
パスワード= * 1（CHAR）/ "0"; VARCHARの長さ> = 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：その名前の階層430：クライアント側411で、現在のデータ許可が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".
PGP-ASCII-装甲開始およびPGP-ASCII-装甲エンド[RFC2440]、セクション6.2に従って構築されている。、 "ASCII装甲を形成します"。
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キー：" CRLFのPGP-答え/「モッド-PGPキー：」CRLFのPGP-答え）]
Examples
例
<-- GETP 0 0 0 humanities
--> 615 data follow
-----BEGIN PGP SIGNED MESSAGE-----
Hash: 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
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)
iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH rRynPhhjveiY/XBkkrrZFho=
iD8DBQE9Zj / Wn13IYldLZg8RAhWiAJ4y7o + 3FzBpRjYJj2HWwXyG2g8FoQCfeEsH rRynPhhjveiY / XBkkrrZFho =
=muK4
-----END PGP SIGNATURE-----
.
<-- GETP 0 0 19990909101000 de --> 213 You are up-to-date .
< - GETP 0 0 19990909101000デ - > 213あなたは最新です。
<-- GETP foo --> 510 Syntax error Missing parameters .
< - GETP FOO - > 510構文エラー不足しているパラメータ。
<-- GETP guest test 0 de --> 430 You have no permission to retrieve the data .
< - GETPゲストテスト0デ - > 430あなたがデータを取得する権限がありません。
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」および「LIST」と同じです。
geta-cmd = "GETA" WSP username WSP password WSP timestamp WSP name CRLF
下駄-CMD = "GETA" 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 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
215：クライアントがすでに現在のデータ430を持っている：許可が411を否定しません：要求されたすべてのデータの下駄回答=「615」[answertext] CRLF PGP-ASCII-鎧スタートと正規の答え：構文エラー615：その名前510を持つん階層を;これは、[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キー：" CRLFのPGP-答え/「モッド-PGPキー：」CRLFのPGP-答え）]
Example
例
<-- GETA 0 0 0 humanities
--> 613 data follow
-----BEGIN PGP SIGNED MESSAGE-----
Hash: 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
COMP-長さ：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ステータス：シリアル司会：20020821094533説明：定期的なUSENETの記事のためのリポジトリ。 （モデレート）のMod-SUB-ADR：news-answers@mit.edu.exampleのMod-ADM-ADR：news-answers-request@mit.edu.exampleニュースグループタイプ：日付は、作成発表：19950725182040
Name: humanities.classics
[...]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (IRIX64)
iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH
rRynPhhjveiY/XBkkrrZFho=
=muK4
-----END PGP SIGNATURE-----
.
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戻りコード（構文エラー：不足しているパラメータ）の後に発生した場合に与えられます。
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
ヘッダの内容は、限り、階層内の継承であります
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」です。
Hierarchies and newsgroups must have at least values for the headers "Name" and "Status". Unknown hierarchies or groups get the status "Unknown".
階層やニュースグループは、ヘッダー「名前」と「状態」のための少なくとも値を持っている必要があります。不明な階層またはグループは、ステータスが「不明」を取得します。
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
階層必須：はい継承：いいえ反復：なし説明：のために使用される名前は、階層の。コメント：新しいデータブロックのスタートを。例：名前：コンプ
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
中古：ニュースグループは必須：はい反復可能：いいえ説明：ニュースグループのコメントの名前：新しいデータブロックのスタート。例：名前：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
階層必須：はい継承：いいえ反復：なし説明：階層のステータスのために使用します。コメント：詳細については、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
必須のニュースグループ：はいに使用が反復：なし説明：ニュースグループのステータス。コメント：詳細については、6.4節を参照してください。例：ステータス：グループ、モデレート
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
階層必須：：のために使用されていない何も継承：いいえ反復：なし説明：タイムスタンプを階層データのために。コメント：詳細については、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
必須のニュースグループ：：のために使用されていない何も継承：いいえ反復：なし説明：タイムスタンプをニュースグループのデータのために。コメント：詳細については、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.
中古：ニュースグループは必須：いいえ反復：なし説明：名前モデレートグループのフォローアップ転記を取るニュースグループの。コメント：モデレートグループへの転記にヘッダ：値が「フォロー-TO」のデフォルト値として使用することができます。この値は、モデレートされているグループでのみ有効です（ステータスグループ-モデレート）と、専用のディスカッショングループを持っています。
Example: Followup: bln.announce.fub.zedat.d (for the moderated group bln.announce.fub.zedat)
例：フォロー：bln.announce.fub.zedat.d（モデレートグループbln.announce.fub.zedat用）
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)
階層必須：：のために使用されていない何も継承：いいえ反復：なし説明：階層の短い説明。例：概要：Angelegenheiten、（階層BLN用）ダイデン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)
必須のニュースグループ：：のために使用されていない何の反復：なし説明：ニュースグループの短い説明。コメント：この情報は、多くの場合、ニュースグループを選択するとニュースリーダに提示され、それは短いが、トピックのわかりやすい説明する必要があります。例：概要：Technischesツア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)
階層必須：いいえ継承：いいえ反復可能：はい説明：階層のチャーターを指すURLに使用します。例：チャーターます。ftp：（階層BLN用）//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
必須のニュースグループ：：のために使用される無反復可能：はい説明：ニュースグループのチャーターを指すURL。コメント：この情報は、ニュースグループの選択時にニュースリーダーに提示しなければなりません。例：チャーターます。ftp：//ftp.fu-berlin.de.example/doc/news/bln /bln.markt.arbeit
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
階層必須：：のために使用されていない何も継承：はい反復可能：はい説明：URL階層のネチケットを指します。コメント：netiquettesは、多くの場合、完全な階層のために有効であるので、これは継承可能です。例：ネチケットます。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)
必須のニュースグループ：：のために使用される無反復可能：はい説明：ネチケットのためのURL。コメント：グループは、いくつかの特別なルールを持っている場合、これは、これらの規則へのポインタです。例：ネチケットます：http：（bln.markt用）//go.to.example/bln.markt
Frequently Asked Questions (FAQ)
よくある質問（FAQ）
Header: FAQ
ヘッダー：よくある質問
Used for: Newsgroup Mandatory: no Repeatable: yes Description: URL for the FAQ of a newsgroup. Example: FAQ: http://www.dard.de.example/
必須のニュースグループ：：のために使用される無反復可能：はい説明：ニュースグループのよくある質問のための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.
階層必須：：のために使用されていない何も継承：はい反復は：はい説明：URL、作成、削除、またはこの階層でのニュースグループの名前を変更するための規則を記述した文書を指します。コメント：通常、トップレベルの階層から継承されました。
Example: Rules: http://www.kirchwitz.de.example/~amk/dai /einrichtung
例：ルールます。http：//www.kirchwitz.de.example/~amk/dai /デバイス
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
階層必須：：のために使用されていません継承：はい反復可能：はい説明：制御メッセージの送信者の電子メールアドレス。コメント：複数のアドレスが有効です。例：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
階層必須：：のために使用されていない何も継承：はい反復可能：はい説明：名前checkgroups、rmgroup、およびニュースグループの制御メッセージの投稿を取得するニュースグループのは。例：CTL-ニュースグループ：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)
階層必須：：のために使用されていません継承：はい反復可能：いいえ説明：この階層の司会ワイルドカード。コメント：この情報は、INNでのモデレーターファイルを設定するには、例えば、ニュースソフトウェアの設定のために使用することができます。例：Modのワイルドカード：（階層デ用）%s@moderators.dana.de.example
Submission address
応募アドレス
Header: Mod-Sub-Adr
ヘッダー：Modの-SUB-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)
必須のニュースグループ：：のために使用される無反復可能：はい説明：ニュースグループへの投稿のための電子メールアドレス。コメント：なし「のMod-SUB-ADRは」モデレートニュースグループのために存在しない場合、階層の「モッズ・ワイルドカードは、」使用されています。これはモデレートグループ（ステータスグループ-モデレート）のために有用です。例：ModのサブADR：（ニュースグループnews.answersにするため）news-answers@mit.edu.example
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)
必須のニュースグループ：：のために使用される無反復可能：はい説明：ニュースグループのモデレータの電子メールアドレス。コメント：モデレートニュースグループのためのコード「のMod-ADM-ADR」がない場合は、階層の「モッズ・ワイルドカードは、」使用されています。これはモデレートグループ（ステータスグループ-モデレート）のために有用です。例：モッド-ADM-ADR：（ニュースグループnews.answersにするため）news-answers-request@mit.edu.example
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)
必須のニュースグループ：：のために使用されていない何の反復：Yes説明：URLモデレータはニュースグループや記事の提出についての情報を提示した文書を指します。例：モッズ・グループ情報：http://www.example.org/cola-submit.html（にcomp.os.linux.announce用）
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)
階層必須：：のために使用されていない何も継承：はい反復可能：はい説明：通常の投稿に使用される言語を。コメント：表記は、[RFC2616]の「Content-言語」フィールドに従ってあります。好ましいものではない言語が括弧で囲まれています。例：言語：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)
必須のニュースグループ：：のために使用されていない何の反復：Yes説明：通常の投稿に使用される言語を。コメント：表記は、[RFC2616]の「Content-言語」フィールドに従ってあります。好ましいものではない言語が括弧で囲まれています。例：言語：TR言語：DE言語：（EN）（ニュースグループbln.kultur.tuerkisch用）
Charset
文字セット
Header: 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)
階層必須：：のために使用されていない何も継承：はい反復可能：はい説明：文字セット、通常はこの階層での投稿に使用されます。コメント：文字セット名の完全なセットは、[RFC2277]とIANA文字セット登録[IANA-CS]で定義されています。有利な文字セットではない文字セットは、括弧で囲まれています。例：文字セット：（階層ド用）ISO-8859-1
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)
必須のニュースグループ：：のために使用されていない何の反復：Yes説明：文字セット、通常はこのグループに投稿に使用されます。コメント：文字セット名の完全なセットは、[RFC2277]とIANA文字セット登録[IANA-CS]で定義されています。有利な文字セットではない文字セットは、括弧で囲まれています。例：文字セット：ISO-8859-9文字セット：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
階層必須：：のために使用されていません継承：はい反復可能：はい説明：MIME [RFC2045]によると、この階層のエンコーディング。コメント：これは、この階層で使用されるメディアタイプです。登録されたメディアタイプのリストは、[IANA-MT]で見つけることができます。好ましくないエンコーディングは、括弧で囲まれています。例：text / plainのエンコーディング
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
必須のニュースグループ：：のために使用される無反復可能：はい説明：MIME [RFC2045]によると、このニュースグループのためのエンコーディング。これは、このニュースグループで使用されるメディアタイプでコメント。登録されたメディアタイプのリストは、[IANA-MT]で見つけることができます。好ましくないエンコーディングは、括弧で囲まれています。例：エンコーディング：テキスト/平野
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)
階層必須：：のために使用されていない、この階層内のデフォルトニュースグループの種類：なし継承：はい反復可能：はい説明。コメント：このヘッダは、階層のための具体的な意味を持ちませんが、階層内のニュースグループへの継承のために使用されています。タイプの仕様は、6.5節に記載されています。例：ニュースグループタイプ（階層デ用）ディスカッション
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)
必須のニュースグループ：：のために使用される無反復可能：はい説明：ニュースグループのタイプ。コメント：タイプの仕様は、6.5節に記載されています。例：ニュースグループタイプ：（de.admin.news.announceのために）発表
Type of hierarchy
階層のタイプ
Header: Hier-Type
ヘッダー：ハイアー型
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)
階層必須：：のために使用されていません継承：はい反復可能：はい説明：階層のタイプ。コメント：タイプの仕様は、セクション6.6に記載されています。例：ハイアー型：地域（階層BLN用）
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)
階層必須：継承なし：はい反復：Yes説明：この階層の地理的地域の説明や組織のために使用されます。コメント：階層型（ハイアー型）が「地域」または「組織」である場合、このコードは有用です。例：エリア：（階層BLN用）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)
階層必須：：のために使用されていないニュースグループ名の最大長：なし継承：はい反復可能：いいえ説明。例：名前の長さ：72（階層BLN用）
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)
階層必須：：のために使用されていません継承：はい反復可能：いいえ説明：ニュースグループ名で単一コンポーネントの最大長。例：COMP-長さ：14（階層デ用）
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
階層必須：：のために使用されていないバイト単位での物品の最大長：なし継承：はい反復可能：いいえ説明。コメント：このヘッダは、階層のための具体的な意味を持ちませんが、階層内のニュースグループへの継承のために使用されています。例：記事-長さ：50000
Used for: newsgroup Mandatory: no Repeatable: no Description: Maximum length of an article in bytes. Example: Article-Length: 50000
中古：ニュースグループは必須：いいえ反復：なし説明：バイト単位での記事の最大長。例：記事-長さ：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
階層必須：：のために使用されていない何も継承：はい反復：なし説明：階層の作成日は、でも将来的にすることができます。コメント：フォーマットは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
必須のニュースグループ：：のために使用されていない何の反復：なし説明：ニュースグループの作成日。でも将来的にすることができます。コメント：フォーマットはDATEコマンドと同じです。例：日付-作成：19970330101514
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
階層必須：：のために使用されていない何も継承：はい反復：なし説明：階層の除去の日は、でも将来的にすることができます。コメント：フォーマットは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
必須のニュースグループ：：のために使用されていない何の反復：なし説明：ニュースグループの除去の日。でも将来的にすることができます。コメント：フォーマットは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)
階層必須：：のために使用されていない何の継承：なし反復可能：はい説明：名前ステータスが「階層-廃止」であるか、除去の日付が未来にある場合、階層を交換する場合は削除階層を交換し、階層の。例：置換：（階層サブための）デ
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)
必須のニュースグループ：：のために使用されていない何の反復：Yes説明：名前ステータスが「グループ除去」であるか、除去の日付が未来にある場合、ニュースグループを交換する場合は削除されたニュースグループを置換するニュースグループまたはニュースグループの。例：交換：bln.markt.arbeit（bln.jobs用）
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)
組織またはこの階層の責任者へのポインタ：階層必須：：のために使用されていない何も継承：はい反復：なし説明。 URLやメールアドレスでなければなりません。例：出典：のhttp：（階層ド用）//www.dana.de.example/mod/
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-----
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.
必須のニュースグループ：：のために使用されていない何の反復：Yes説明：公開PGPキー（追加情報：キー所有者、キーIDなど）をこのニュースグループのモデレータのを。コメント：正確なフォーマットは、6.7節の例で説明されます。セクション6.7を参照してください。
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
----------- --------- -------------------------------------------
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 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)
Robots Automatic postings (like the former comp.mail.maps)
Experiment Experimental, other
----------- ------------------------------------------------------
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.
階層構造を説明するために、次のような階層型が使用されています。これらのタイプは、ニュースの階層のいくつかのプロパティをマークするために使用されています。彼らは、大文字と小文字を区別しません。
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)
-------------- ---------------------------------------------------
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 CRLF "F" ID-キーSPフィンガーCRLF※（ "L" SP場所CRLF）*（」 K-」キーブロックCRLF） "K" SPキーブロックCRLF
Version = text User-ID = text Bits = text Key-ID = text Finger = text Location = text Keyblock = text
バージョン=テキストユーザーID =テキストビット=テキストキーID =テキスト指=テキスト場所=テキストキーブロック=テキスト
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
--- --------- --------- --------------------------------------
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-----
[...]
.
。
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は、読み取りプログラム（ニュースリーダー）のために意図しています。それは、この文書の範囲ではありません。 NASのためのUDPの使用は、別の論文に説明します。
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必要なパラメータ：なしオプションのパラメータ：レベル
The NAS protocol level number for the enclosed
NAS data package. If not present, the
protocol level defaults to 1.
Encoding scheme: NAS data is plain text; no special encodings are needed.
符号化方式：NASデータはプレーンテキストです。特別なエンコードは必要ありません。
Security considerations: see below
セキュリティに関する注意事項：下記参照
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.
より強力な認証方式は、より高いプロトコルレベルで提供されます。
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)
---- --------------------------------------------------------------
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
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
------------- --------- --- -------- ---------------------
N: Newsgroup, H: Hierarchy
N：ニュースグループ、H：階層
[IANA-CS] IANA: Character Sets, <http://www.iana.org/assignments/character-sets>.
[IANA-CS] IANA：文字セット、<http://www.iana.org/assignments/character-sets>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440]カラス、J.、Donnerhacke、L.、フィニー、H.、およびR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、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.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[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/assignments/port-numbers>。
[RFC1305] Mills, D., "Network Time Protocol", RFC 1305, University of Delaware, March 1992.
[RFC1305]ミルズ、D.、 "ネットワークタイムプロトコル"、RFC 1305、デラウェア州、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>.
[SON1036] H.スペンサー、 "ニュース記事のフォーマットと伝送"、RFC 1036承継のためのドラフト、<ftp://zoo.toronto.edu/pub/news.txt.Z>。
[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).
この作品は、ドイツ連邦教育研究省（Bundesministerium fuerビルドゥングウントForschung）からの資金でドイツ学術ネットワーク組織（DFN-Verein）によって支えられてきました。
Authors' Addresses
著者のアドレス
Philipp Grau Vera Heinau Heiko Schlichting Robert Schuettler
フィリップ・グレーベラHeinauハイコSchlichtingロバート・シュットラー
Freie Universitaet Berlin ZEDAT Fabeckstr. 32 14195 Berlin Germany
ベルリンZEDAT Fabeckstr自由大学。 32 14195ベルリンドイツ
Phone: +49 30 838-74707 Fax: +49 30 838-56721
電話：+49 30 838-74707ファックス：+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/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及び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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。