[要約] RFC 4707は、Netnews Administration System（NAS）に関する標準化されたプロトコル仕様です。NASの目的は、Netnewsシステムの管理を効率化し、管理者がニュースグループや記事の制御を容易にすることです。
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)
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用などのIETFレビューに基づいていないことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。
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 Administration 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サーバーから自動的にまたはユーザーの裁量で特定の情報を取得することができ、グループと階層に関する詳細情報をユーザーに提供します。
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のやや混oticとした構造を反映することができます。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.
NetNews Administration 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.
クライアントがサーバーに接続し、サーバーが認証を要求するという事実により、これはコントロールメッセージよりも情報を送信するためのより合理的な手順です。
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、LightWeight Directory Access Protocol（LDAP）、またはネットワーク情報サービス（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、de。*、us。*、bln。*、fr。*、it。*）。
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。！バイナリ、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サーバーを使用するかを選択できます。
.............. .............. ...................
. 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の実際の使用により、NetNews管理システムの要件が変更されると予想されます。一方では、改善を実装するために、プロトコルは拡張可能かつ柔軟でなければなりません。一方、異なるバージョン間の互換性を確保する必要があります。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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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
回答= Response-Code [nessertext] CRLF TEXT 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 .
<-> 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 5xx Request is wrong (syntax error), is not implemented, or leads to an internal error 6xx Request successful, data follow until end mark
1xx情報2xxリクエスト成功3xxリクエストの成功、データは4xx要求に従います。
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デバッグ出力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は通常、ポート991を使用します。ポート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.
クライアントがサーバーにアクセスする許可がないために接続が拒否された場合、Answerコードは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メッセージを送信した後、接続は閉じられます。
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
answertext = WSP *( ALPHA / DIGIT / "+" / "-" / "/" / "_" /
"." / "," / ":" / "=" / "?" / "!" / SP )
utc-time = 14DIGIT ; the date and time of the server in UTC ; YYYYMMDDhhmmss
UTC-Time = 14Digit;UTCのサーバーの日付と時刻。yyyymmddhhmmss
response-code = 3DIGIT ; three digit number 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.
Response-Code = 3Digit;次のABNF定義に従って、3桁のニュースグループ名と階層名が定義されています。階層名はニュースグループ名（階層bln.announce.fub。*およびnewsgroup名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 / "+" / "-" / "_"
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]に関連しています。ドキュメント「ニュース記事形式」[suesfor]が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
help-cmd = "help" [wsp commandname] crlf
commandname = "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
Examples
例
<-- 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
サポートされているコマンド：データ - ニュースグループのデータ - UTC getpでサーバーの時間を表示 - パッケージGETAを取得 - 権威あるサーバーヘルプからデータを取得 - このヘルプhier-階層情報のデータ - 現在の接続リストに情報を表示 - リストニュースグループまたは階層LSTR -Recursive List NewsGroupsまたはHierarchies Quit -Connection Bersを閉じます - 現在のプロトコルレベルを表示または設定します
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リストリスト - リストニュースグループまたは階層構文：リスト階層...パラメーター階層の下で直接ニュースグループとサブ階層のリストを取得します。
<-- HELP NOOP --> 410 unknown command "NOOP" .
<-HELT NOOP-> 410不明なコマンド「NOOP」。
Description
説明
Prints information about the current connection, the server, and the client.
現在の接続、サーバー、クライアントに関する情報を印刷します。
info-cmd = "INFO" CRLF
info-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
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
<-> 101情報はサーバーに続きます：nas.example.org（192.0.2.100）アップタイム：2週間、3日、5時間、9分ソフトウェア：NAS 1.0クライアント：client.example.org（192.0.2.123（192.0.2.123））接続：9分最高のプロトコルレベルサポート：1要求されたプロトコルレベル：1プロトコルレベル使用：1
End .
終わり 。
<-- INFO --> 400 No information available. .
< - 情報 - > 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（ユニバーサル調整時間）のサーバーの現在の時刻を印刷し、その後オプションのコメントが続きます。日付コマンドは、情報の使用とサーバーの時間を確認するためのみです。ネットワーク上の時間の定期的な送信には、ネットワーク時間プロトコル（NTP）[RFC1305]を使用する必要があります。
date-cmd = "DATE" CRLF
date-cmd = "date" crlf
Possible answers
考えられる答え
300: Print the UTC time in specified format; see below
511: Error; print an error message
date-answer = "511" [answertext] CRLF text CRLF "." CRLF
date-answer = "511" [assertext] crlf text crlf "。"。CRLF
date-answer =/ "300" [answertext] CRLF
utc-time [answertext] CRLF
"." CRLF
Examples
例
<-- DATE --> 300 19990427135230 UTC .
< - 日付 - > 300 19990427135230 UTC。
<-- DATE --> 511 Time is unknown .
< - 日付 - > 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 Commandは、クライアントとサーバー間で使用するプロトコルレベルを決定するために使用されます。パラメーターは、クライアントがサポートし、使用したいプロトコルレベルです。サーバーは、受け入れられた最高レベルで応答します。このバージョン番号は、クライアントが要求したものよりも高くてはなりません。クライアントとサーバーは、サーバーが確認したレベルのコマンドのみを使用する必要があります。クライアントリクエストによるセッション中にプロトコルレベルを変更することは可能ですが、めったに必要ありません（Vers [プロトコルレベル]）。オプションが与えられない場合、現在のプロトコルレベルが印刷されます。プロトコルレベルが交渉されない場合、プロトコルレベル1が使用されます。より高いレベルのコマンドは、交渉を成功させることなく許可されません。プロトコルレベルの後にオプションのコメントが続くことができます。
vers-cmd = "VERS" [WSP level] CRLF
vers-cmd = "vers" [wsp level] crlf
level = 1*5DIGIT ; the valid range is 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-answer = "202" [assertext] crlf level [assertext] 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
Examples
例
<-- VERS --> 202 2 Current protocol level is 2 .
<-ver-> 202 2現在のプロトコルレベルは2です。
<-- VERS 2 --> 302 2 My max protocol level is 10 .
<-2 vers 2-> 302 2私の最大プロトコルレベルは10です。
<-- VERS 11 --> 402 10 Falling back to level 10 .
<-11-> 402 10レベル10に戻る。
<-- VERS BAL --> 510 1 Syntax error .
<-vers bal-> 510 1構文エラー。
Description
説明
Terminates the connection.
接続を終了します。
quit-cmd = "QUIT" CRLF
quit-cmd = "quit" crlf
Possible answers
考えられる答え
201: Termination of the connection
201：接続の終了
quit-answer = "201" [answertext] CRLF Example
Quit-Answer = "201" [nessertext] crlfの例
<-- 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.
データは、1行あたりのニュースグループまたは階層名/ステータスインジケータペアで構成されています。名前とステータスのインジケーターは、少なくとも1つの空白で分離する必要があります。ステータスインジケータは単語です（セクション6.4を参照）。解釈はケースに敏感ではありません。
list-cmd = "LIST" ( WSP "*" / 1*(WSP name)) 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
listdata = name WSP list-status
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" /
list-status = "complete" / "不完全" /「時代遅れの " /" nownowed " /" unmoderated " /" readonly " /" / "
"Moderated" / "Removed" ; list-status is case-insensitive
「モデレート」 /「削除」;リストステータスはケース非感受性です
Examples
例
<-- LIST * --> 610 data follow alt Incomplete comp Complete de Incomplete rec Complete sub Obsolete .
< - リスト * - > 610データは、Alt不完全なComp Complete De不完全なRec Complete Sub 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不完全なde.comm complete de.comp完全なde.etc complete de.markt complete de.newusers complete de.org complete de.rec complete de.sciを完全にフォローしています完全なde.soc complete de.AnswersモデレートDe.testは変更されていません。
<-- LIST foo --> 610 data follow foo Unknown .
<-リストfoo-> 610データは、foo nokningに従います。
<-- LIST --> 510 Syntax error missing parameter hierarchy .
<-リスト - > 510構文エラーが欠落しているパラメーター階層。
<-- LIST de --> 401 Something is wrong Permission denied .
<-リストde-> 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
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
listdata = name WSP list-status
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
list-status = "complete" / "不完全" /「時代遅れの " /" noknowed " /" unmoderated " /" readonly " /" moderated " /" removed ";リストステータスはケース非感受性です
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- abuse complete de.admin.net-abuseモデレートde.admin.net-abuse.mailの未変更のde.admin.net-abuse.misc unmoderated de.admin.net-abuse.news news unmoderated de.admin.news complete de.admin.news.nounceモデレートDe.adminmin.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 name）[wsp selection] crlf
selection = *( "," header ) ; Describes the data fields
; that are requested
header = ALPHA *( ALPHA / "-" ) ; According to section 6.3.4
Example for selection
選択の例
,Followup,Description : For all entries list Name, Status, Followup and Description
、フォローアップ、説明：すべてのエントリリスト名、ステータス、フォローアップ、説明
Possible answers
考えられる答え
401: Permission denied 510: Syntax error 611: Regular answer with all requested data
401：許可拒否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
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)]
PGP-answer: The exact format is described in Section 6.7.
PGP-Answer：正確な形式については、セクション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 bln --> 401 Permission denied .
<-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.
データコマンドは、6.3.3.8で説明されているように、Hierコマンドに対応していますが、ニュースグループに関する情報に使用されます。コードの概要は、セクション6.3.4に記載されています。
data-cmd = "DATA" 1*(WSP name) [WSP selection] CRLF
data-cmd = "data" 1*（wsp name）[wsp selection] 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
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)]
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
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
<-datede.foo-> 612データフォロー名：de.fooステータス：不明
.
。
<-- DATA de --> 401 Permission denied .
<-date 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の回答が送信されるため、クライアントはそのデータが問題ないことを知っています。タイムスタンプが「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].
成功したリクエストのデータは署名され、[RFC2440]に従ってASCIIアーマーで送信されるため、クライアントは署名を確認したり、無視したりできます。[RFC2440]のセクション6.2によると、実際のデータは装甲の開始および終了セクションに囲まれます。
getp-cmd = "GETP" WSP username WSP password WSP timestamp WSP ( name / "*" ) CRLF
getp-cmd = "getp" wspユーザー名wspパスワードwspタイムスタンプwsp（name / "*"）crlf
username = *1( VCHAR ) / "0" ; Length of VCHAR >= 1
password = *1( VCHAR ) / "0" ; Length of VCHAR >= 1
timestamp = utc-time / ; date and time of the last retrieval
"0" ; force the transmission of data
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
pgp-ascii-armor-start and the pgp-ascii-armor-end are built according to [RFC2440], Section 6.2., "Forming ASCII Armor".
PGP-ASCII-ARMOR-STARTおよびPGP-ASCII-ARMOR-ENDは、[RFC2440]、セクション6.2、「ASCII Armorの形成」に従って構築されています。
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)]
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 DE-> 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 DE-> 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
geta-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
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)]
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
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=
=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」（ドイツ語）があります。したがって、この値は、独自の言語コードを明示的に定義するものを除き、この階層のすべてのニュースグループの「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
使用：階層を必須：はい継承可能：繰り返しなし：説明なし：階層の名前。コメント：新しいデータブロックの開始。例：名前：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
使用：NewsGroup Tancoration：はい繰り返し：いいえ：説明：NewsGroupの名前コメント：新しいデータブロックの開始。例：名前：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を参照してください。例：ステータス：Hierarchy-Complete
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 Serial
使用：NewsGroup Tancoration：はい繰り返し：いいえ説明：ニュースグループのステータス。コメント：詳細な説明については、セクション6.4を参照してください。例：ステータス：グループ構造シリアル
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
使用：NewsGroup Tangatory：継承なし：繰り返しなし：説明なし：ニュースグループデータのタイムスタンプ。コメント：詳細な説明については、セクション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.
使用：NewsGroup Tancoration：繰り返しなし：説明なし：モデレートグループのフォローアップ投稿を取得するニュースグループの名前。コメント：値は、「フォローアップ」のデフォルト値として使用できます。この値は、モデレート（ステータスグループが制定）され、専用のディスカッショングループを持つグループでのみ有用です。
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、Die Den Grossraum Berlin Betreffen（階層BLN用）
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)
使用：NewsGroup Tancoration：繰り返しなし：説明なし：ニュースグループの短い説明。コメント：この情報は、ニュースグループの選択時にニュースリーダーに提示されることがよくあり、トピックの簡単で意味のある説明である必要があります。例：説明：Technisches Zur NewsSoftware（de.admin.news.software用）
Charter-URL
Charter-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)
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
使用：NewsGroup Tancoration：繰り返しなし：はい説明：ニュースグループのチャーターを指すURL。コメント：この情報は、ニュースグループの選択時にニュースリーダーに提示する必要があります。例：チャーター：ftp：//ftp.fu-berlin.de.example/doc/news/bln /bln.markt.arbeit
Netiquette-URL
Netiquette-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。コメント：ネチケットは完全な階層に対して有効であることが多いため、これは継承可能です。例：Netiquette：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)
使用：NewsGroup Tangatory：繰り返しなし：はい説明：Netiquette用のURL。コメント：グループにいくつかの特別なルールがある場合、これはこれらのルールへのポインターです。例：Netiquette：http：//go.to.example/bln.markt（for 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/
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
Control Email
電子メールを制御します
Header: Ctl-Send-Adr
ヘッダー：CTL-SEND-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
Control newsgroup
コントロールニュースグループ
Header: Ctl-Newsgroup
ヘッダー：CTL-NewsGroup
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
使用：階層を必須：継承なし：はい繰り返し：はい説明：チェックグループ、rmgroup、およびニュースグループ制御メッセージの投稿を取得するニュースグループの名前。例：CTL-NewsGroup：de.admin.news.groups
Moderators
モデレーター
Header: Mod-Wildcard
ヘッダー：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-wildcard：％s@moderators.dana.de.example（階層de用）
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)
使用：NewsGroup Tancoration：繰り返しなし：はい説明：ニュースグループへの送信の電子メールアドレス。コメント：モデレートされたニュースグループに「mod-sub-adr」がない場合、階層の「mod-wildcard」が使用されます。これは、モデレートグループ（ステータスグループモデレート）のみに役立ちます。例：mod-sub-adr：news-answers@mit.edu.example（NewsGroup News.Answers用）
Moderator's address (email)
モデレーターのアドレス（電子メール）
Header: Mod-Adm-Adr
ヘッダー：mod-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)
使用：NewsGroup Tancoration：繰り返しなし：はい説明：ニュースグループのモデレーターの電子メールアドレス。コメント：モデレートニュースグループのコード「mod-adm-adr」がない場合、階層の「mod-wildcard」が使用されます。これは、モデレートグループ（ステータスグループモデレート）のみに役立ちます。例：mod-adm-adr：news-answers-request@mit.edu.example（NewsGroup News.Answers用）
Info-URL
info-url
Header: Mod-Group-Info
ヘッダー：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)
使用：NewsGroup Tancoration：繰り返しなし：はい説明：モデレーターがニュースグループと記事の提出に関する情報を提示するドキュメントを指すURL。例：mod-group-info：http：//www.example.org/cola-submit.html（for 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]の「コンテンツ言語」フィールドに従っています。好まない言語は括弧内に囲まれています。例：言語：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)
使用：NewsGroup Tancoration：繰り返しなし：はい説明：通常、投稿で使用される言語。コメント：表記は[RFC2616]の「コンテンツ言語」フィールドに従っています。好まない言語は括弧内に囲まれています。例：言語：TR言語：de言語：（ en）（NewsGroup 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)
使用：階層を必須：継承なし：はい繰り返し：はい説明：この階層の投稿で通常使用されるチャーセット。コメント：Charset名の完全なセットは、[RFC2277]とIANA文字セットレジストリ[IANA-CS]によって定義されます。好ましい充電器ではない充電器は、括弧内に囲まれています。例：Charset：ISO-8859-1（階層DEの場合）
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)
使用：NewsGroup Tancoration：繰り返しなし：はい説明：このグループの投稿で通常使用されるCharset。コメント：Charset名の完全なセットは、[RFC2277]とIANA文字セットレジストリ[IANA-CS]によって定義されます。好ましい充電器ではない充電器は、括弧内に囲まれています。例：Charset：ISO-8859-9 Charset：ISO-8859-1（NewsGroup 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]にあります。好まないエンコーディングは、括弧内に囲まれています。例：テキスト/プレーンのエンコード
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 Type of newsgroup
使用：NewsGroup Tancoration：繰り返しなし：はい説明：MIME [RFC2045]によるこのニュースグループのエンコード。コメントこれは、このニュースグループで使用されているメディアタイプです。登録メディアタイプのリストは[IANA-MT]にあります。好まないエンコーディングは、括弧内に囲まれています。例：エンコーディング：テキスト/プレーンタイプのニュースグループ
Header: Newsgroup-Type
ヘッダー：NewsGroupタイプ
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にあります。例：NewsGroup-Type：ディスカッション（階層のための）
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)
使用：NewsGroup Tancoration：繰り返しなし：はい説明：ニュースグループのタイプ。コメント：タイプの仕様は、セクション6.5にあります。例：NewsGroup-Type：Announce（De.Admin.News.Announce用）
Type of hierarchy
階層の種類
Header: Hier-Type
ヘッダー：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に記載されています。例：Hier-Type：地域（階層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)
使用：階層を必須：継承なし：はい繰り返し：はい説明：地理的領域またはこの階層の構成の説明。コメント：このコードは、階層タイプ（Hier-Type）が「地域」または「組織」である場合に役立ちます。例：エリア：Grossraum Berlin（ヒエラルキーBLN用）
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)
使用：階層を必須：継承なし：はい繰り返し：説明なし：ニュースグループ名の最大長。例：name-length：72（階層bln用）
Component length of group names
グループ名のコンポーネントの長さ
Header: Comp-Length
ヘッダー：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-length：14（階層deの場合）
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
使用：NewsGroup Tancoration：繰り返しなし：説明なし：バイトの記事の最大長。例：記事長：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
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 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-Delete：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
使用：NewsGroup Tancoration：繰り返しなし：説明なし：ニュースグループの削除日。将来になることさえできます。コメント：形式は、日付コマンドと同じです。例：Date-Delete：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)
使用：階層を必須：継承なし：繰り返しなし：はい説明：ステータスが「階層 - オブソレテ」である場合、削除された階層を置き換える階層の名前、または除去の日付が将来の場合は階層を置き換えます。例：交換：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)
使用：NewsGroup Tancoration：繰り返しなし：はい説明：削除されたNewsGroupを「グループが削除した」場合に削除されたニュースグループを置き換えるニュースグループまたはニュースグループの名前、または削除の日付が将来にある場合はNewsGroupを置き換えます。例：交換：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/（hierarchy deの場合）
E: This is for tracking the maintainer of a hierarchy.
E：これは、階層のメンテナーを追跡するためのものです。
Control PGP key
PGPキーを制御します
Header: Ctl-PGP-Key
ヘッダー：CTL-PGP-KEY
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
Header: Mod-PGP-Key
ヘッダー：mod-pgp-key
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.
使用：NewsGroup Tancoration：繰り返しなし：はい説明：このNewsGroupのモデレーターのパブリック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.
ニュースグループタイプは、テストグループ、バイナリグループ、またはその他の種類であるニュースグループのいくつかの特性に関する包括的な概要です。NewsGroup 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)
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-KEYおよびMOD-PGP-KEYの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
Version = text
User-ID = text
Bits = text
Key-ID = text
Finger = text
Location = text
Keyblock = text
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.
囲まれたNASデータパッケージのNASプロトコルレベル番号。存在しない場合、プロトコルレベルはデフォルト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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Callas、J.、Donnerhacke、L.、Finney、H。、およびR. Thayer、「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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、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] Mills、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. Spencer、「ニュース記事形式と送信」、RFC 1036後継者のドラフト、<ftp://zoo.toronto.edu/pub/news.txt.z>。
[USEFOR] USEFOR Working Group, "News Article Format", Work in Progress.
[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 Bildung und Forschung）の資金で、ドイツのアカデミックネットワーク組織（DFN-Verein）によってサポートされています。
Authors' Addresses
著者のアドレス
Philipp Grau Vera Heinau Heiko Schlichting Robert Schuettler
フィリップ・グラウ・ヴェラ・ハイナウ・ハイコ・シュリッシング・ロバート・シュエットラー
Freie Universitaet Berlin ZEDAT Fabeckstr. 32 14195 Berlin Germany
Freie Universitaet Berlin Zedat Fabeckstr。32 14195ベルリンドイツ
Phone: +49 30 838-74707
Fax: +49 30 838-56721
EMail: nas@fu-berlin.de
URL: http://nas.fu-berlin.de/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。