Network Working Group Brian Kantor (U.C. San Diego) Request for Comments: 977 Phil Lapsley (U.C. Berkeley) February 1986 ネットワークニュース転送プロトコル Stream-Based なニュース転送に関する Proposed Standard このメモの位置づけ NNTP は ARPA-Internet コミュニティにおいて、信頼性のある stream-basedな ニュースの転送を用いたニュースアーティクルの配布 (distribution)、照会 (inquiry)、回収 (retrieval)、投稿 (posting) のためのプロトコルを規定する。 NNTP は、ニュースアーティクルを中央データベースに保存し、購読者に読みたい記 事だけ選択させることを許すように設計されている。また、索引付け (indexing) 、他所参照 (cross-reference)、古くなったアーティクルの廃棄 (expiration) 等 の機能も提供する。この RFC は ARPA-Internet コミュニティに対して proposed なプロトコルを提案し、改善のための議論、提案を求めるものである。このメモの 配布は無制限である。 1. はじめに 永年に渡って、ARPA-Internet コミュニティは幾千もの参加組織に向けて告知、 情報、データをその時々に応じた方法によって配布することをサポートしてきてい る。我々は、このような情報の類をまとめて "ニュース (news) " と呼ぶ。 ニュースによって、多くの興味ある話題、例えばソフトウェアのバグ修正、新製品 の評価、技術的な tips、プログラミングのポインタ、実際に作業しているプロのコ ンピュータ技術者に関する事柄の矢継ぎ早の議論といったものが迅速に広められる ようになった。ニュースはその講読者たちにとってポピュラーなものである。 ニュースのような物を配送するための手法として、2 つのものが普及している。 すなわち、直接メールするインターネット的手法と、USENET ニュースシステムであ る。 1.1 メーリングリスト インターネットコミュニティは、メーリングリストを利用してニュースを配布し ている。メーリングリストは、購読者のメールボックスアドレスや、参加者に再配 送するような (メーリングリストの) ポインタがリストになったものである。 このようなメーリングリストは、配布すべき情報のコピーを購読者それぞれに再度 メールする。この再度メールする仕組は、購読者の数がダース以上に増えてくると 非効率になる。各購読者に別々のコピーを配送すると、多大なネットワークのバン ド幅、対象ホストの CPUリソース、ディスク領域を占有するからである。 リストそのものの保守も問題である。購読者が転職した場合や、新しい購読者が加 入し、古い購読者が止めた場合、あるいはホストがサービスに加わったり消えたり した場合、全て保守が発生する。 1.2 USENET ニュースシステム アーティクルが購読者のメールボックスの替わりに中央データベースに保存され るならば、明らかに使用リソースの大幅削減が達成される。USENET ニュースシステ ムは、まさにこの方法を提供するものである。すなわち、ニュース保存場所 (慣例 上、ある種のスプールディレクトリが用いられる) と、購読者が読みたい記事を選 択し、読むことができる環境を提供するプログラムである。また、索引付け、他所 参照、古いメッセージの廃棄といった機能も提供される。 1.3 ニュースのセントラル・ストレージ 互いに高速 LAN (イーサネットのような) に接続されているホスト群に対しては、 ニュース配布をネットワーク上の 1 台 (もしくは少数台) に統合し、クライアント - サーバモデルを用いてニュース記事にアクセスさせる方がより理にかなっている。 購読者は読みたい記事をただリクエストするだけでよく、各ホストはそれぞれ無駄 な複製を持つ必要がなくなる。 1.4 セントラル・ニュースサーバ ニュース配送を経済的に達成する方法は、LAN 上のシステムにニュースサービス を提供するセントラルRンピュータを導入することである。このようなサーバは、蓄 積されたニュースアーティクルと索引ファイルを、LAN 経由でニュース購読を希望 する人々とあわせて管理する。大規模なコンピュータシステムでは、全体のディス ク容量を削減することは明らかに意味がある。また、こうすることにより、限られ たディスク容量しか持たないワークステーションであっても、ディスク領域がニュー ス記事に圧迫されることなく、ニュースに参加することができるようになる。 我々は IBIS や他の共有/分散ファイルシステムを用いてセントラル・ニュース サービスを提供する試みがある程度成功したと聞いている。同型のコンピュータが 動作し、ほぼ同じ OS が走っているグループ上ならば、このような分散ファイルシ ステムの実装が可能であるが、それはワイドレンジのクライアントシステムに供す るほど一般的ではない。特に、クライアントのグループでは、多種多様な OS が使 われているかもしれない。ワイドレンジでホストのハードウェア、OS を考慮する と、インターネット TCP が提供している stream 接続を用いたサービスのように一 般性を提供できる共有/ネットワークファイルシステムは、あったとしてもごく僅か である。 NNTP はニュースアーティクルを信頼性のある stream型 (TCPのような) サーバ - クライアントモデルを用いて配布、照会、回収、投稿をするためのプロトコルを 規定する。NNTP は、ニュースアーティクルは一箇所の (おそらくは中央) ホストに 蓄積されればよく、購読者は他のホストから LAN を使い、ニュースホストへの stream 接続を用いてニュースアーティクルを読むように設計されている。 NNTP は USENET ニュースシステムを記述した RFC850 のニュースアーティクル仕 様の上でモデル化されている。しかし、NNTP はニュースアーティクルの構造、内 容、蓄積についてわずかな要求仕様しかないので、他の non-USENET ニュースシス テムに適合させることは容易と思われる。 一般に、NNTP サーバはホストのバックグラウンドプロセスとして動作し、LANの 他のホストからの接続を受諾できる。この仕組みは小さなコンピュータシステム (1 人とか数人しかユーザがいないようなワークステーション等) がたくさんあり、大 きなセントラル・サーバがある際に有効である。 1.5 中間のニュースサーバ 多数のユーザを持つマシンが数多くある場合 (大学、大企業などのケースが考え られる)、中間サーバを用いても構わない。この中間または "slave" サーバは各コ ンピュータシステムで動作し、購読のリクエストを仲介し、最近回収されたニュー スアーティクルをローカルにキャッシュする。 典型的には、ニュースサービスを得ようとするクライアントは、はじめにローカ ルマシンのニュースサービス|ートに接続しようと試みる。これが失敗した場合、す なわちサーバがフェイルした場合、インストール時の設定によってニュースアクセ スを不許可にするか、中央の "master" サーバへのアクセスを許可するかを選択す ることができる。 ワークステーションや小規模システムでは、master サーバに直接アクセスするほ うが一般的かもしれない。 この仕様書は、slave NNTP サーバのオペレーションをカバーしていない。我々は 単に slave サーバを大規模 LAN のオペレーションを拡張する NNTP サーバ使用法 の論理的な付加機能として提案するにとどめる。 1.6 ニュースの配布 NNTP は協力しあうホスト間でニュースアーティクルを交換する簡単な手法を提供 している。同一 LAN もしくは他の高速ネットワークに接続されており、ニュース アーティクルをローカルなストレージにコピーしようとするホストに対しては、 NNTP は従来の配送手法 (UUCPのような) より効果的にニュースを配送する。 従来のニュースアーティクル配送手法では、ニュースはホストからホストへの flooding によって伝播されていた。つまり、各ホストは全配送先ホストに対して全 新着アーティクルを送っていた。新しいアーティクルを受け取ったホストは、それ を自身がフィードするホストに送る。他のフィード元 (ニュースを受け取るホスト の多くは冗長にフィードされている) から入手した既に持っているアーティクルを 再び送るのは、明らかに時間と通信リソースの無駄である。対話的 (UNIX の世界で いう UUCP のような) というより、むしろ single-transaction ベースの転送メカ ニズムが存在しないならば、全アーティクルを配送し、だぶったアーティクルを削 除するホストを持つ方が配布時間は短くなる。一日の接続時間が限られているなら、 これは正しい。 NNTP を用いると、ニュースアーティクルを交換しているホストは、あるアーティ クルを受け渡すべきかを決定する対話的なメカニズムを持つ。新しいアーティクル を求めているか、または配送すべき新しいアーティクルを持っているホストは、1 つ以上の neighbor に NNTP を用いてコンタクトする。はじめに、 NEWGROUPS コマ ンドを使ってサービスホスト上に新しいニュースグループが作られているか照会す る。新しいニュースグループがあり、それが適切であるか、こちらの望む (ローカ ルに決められたルールによって選定される) ものであれば、そのニュースグループ が作成される。 クライアントホストは次に NEWNEWS コマンドを用いて、受信を望むニュースグ ループの幾つか、あるいは全てについて、新しいアーティクルが到着していないか 照会する。その後、新しいアーティクルのリストをサーバから受け取り、持ってい ない、受信を希望する記事を転送するようリクエストをすることができる。 最後に、クライアントは自身が最近受け取ったニュースアーティクルについてサー バにアドバイスをすることができる。サーバは既にコピーを持っているアーティク ルと、自身のコレクションに加えるために配送されるべきアーティクルをそれぞれ 表示する。 この方式によれば、重複していない、望まれるアーティクルだけが配送される。 2. NNTP の仕様 2.1 概要 本ドキュメントで規定するニュースサーバは、stream型の接続 (TCP のような) と SMTP に似たコマンドとレスポンスを使用する。また、ホストからの接続を受け 付け、ニュースデータベースへの簡潔なインタフェースを提供するように設計され ている。 このサーバは単にニュースデータベースとプログラム間のインタフェースになっ ている。ユーザとの対話や表示をする機能はない。このような「ユーザフレンドリ」 な機能はクライアントプログラムに残しておいた方が良い。クライアントプログラ ムは自身が操作する環境について、より優れた取り決めがなされている。 インターネットの TCP を用いる場合には、このサービスに対しては 119 番が割 り当てられている。 2.2 キャラクタコード コマンドとそのリプライは ASCII キャラクタセットから構成される。転送サービ スが 8bit バイト (オクテット) 分の転送チャネルを提供する場合、7bit キャラク タは全て先頭 1bit を 0 にクリアし、そのまま右詰めにした形で転送される。 2.3 コマンド コマンドはコマンドワードから構成される。場合によって、パラメータが続くこ ともある。パラメータを伴うコマンドでは、各パラメータとコマンドは、1 つ以上 の空白かタブを用いて互いに離されていなければならない。コマンド行には、コマ ンドに必要な全てのパラメータが記されていなければならない。また、2 つ以上の コマンドを含んでいてはいけない。 コマンドとコマンドパラメータは大文字、小文字で違いはない。すなわち、大文 字であっても、小文字であっても、大文字と小文字が混在していても良い。 コマンド行は CR-LF (キャリッジリターン - ラインフィード) のペアで終わらな ければならない。 コマンド行はその長さが 512 キャラクタを越えてはならない。これは空白、セパ レータ、句読点、CR-LF を含む全キャラクタがカウントの対象となる。 (CR-LFが含 まれるため、コマンドとパラメータの最大長は 510 キャラクタとなる) 。コマンド 行を繋げる記号は存在しない。 2.4 レスポンス レスポンスは2種類ある。テキストとステータスである。 2.4.1 テキストレスポンス テキストは、テキストが後に続くことを示す数字のレスポンス行が送られた後に だけ送信される。テキストはテキスト的に連続して送られる。各行とも CR-LF で止 められる。ピリオド 1 つだけの行は、テキストの終わりを示すものとして送信され る。 (つまり、サーバはテキスト最終行の CR-LF を送信し、ピリオドを送信し、も う 1 度 CR-LF を送信する) 。 オリジナルのテキスト内が 1 文字目がピリオドで始まるテキスト行を含む場合、 1 文字目のピリオドは 2 つにされる。したがって、クライアントは受け取った行の 1 文字目を調べ、ピリオドで始まる行については、テキストの終わりなのか、1 文 字目のピリオドが 2 つにされたものかを判断しなければならない。 この意図は、テキストメッセージは通常ユーザのターミナルに表示され、そこで コマンド、レスポンスは表示前にクライアントプログラムによって翻訳されること にある。 2.4.2 ステータスレスポンス ステータスレスポンスはサーバの状態レポートであり、サーバが最後に受け取っ たコマンドのレスポンスを示すものである。 ステータスレスポンス行は 3 桁の数字コードで始まる。これは全てのレスポンス を識別するのに充分な桁数である。幾つかのものは、続けてテキストが転送される 先触れとなっている。 レスポンスの 1 桁目の数字は、前のコマンドの成功、失敗、進展を大まかに示す ものである。 1xx - 情報を与えるメッセージ 2xx - コマンド OK 3xx - ここまではコマンドOK、残り (のコマンド) を送れ 4xx - コマンドは正しかったが、何らかの理由で実行できなかった 5xx - 指定されたコマンドは実装されていないものか、正しくない。 あるいは重大なプログラムエラーが発生している。 コードの次の桁は機能的なレスポンス領域を示す。 x0x - 接続、設定、その他に関するメッセージ x1x - ニュースグループの選択 x2x - アーティクルの選択 x3x - (アーティクル配布の) 機能 x4x - ポスト (投稿) する x8x - 標準でない (個人的な実装による) 拡張 x9x - デバッグ出力 各コマンドにおいて期待される正確なレスポンスのコードは、そのコマンドに関 する記述の際に詳細を示すことにする。更に、以下にいつ如何なる際にも受け取る 可能性がある、一般的なレスポンスの集合を列挙する。 ある種の状態レスポンスは数字や名前といったパラメータを含んでいる。数字と そのようなパラメータのタイプは、レスポンスの翻訳を簡易にするために、各レス ポンスについてそれぞれ固定される。 パラメータはパラメータ同士と数字のレスポンスコード空白で区切られる。数字 パラメータは全て十進数で、先頭に 0 が付くこともある。文字列パラメータは全て 空白で区切られた後に始まり、区切りの空白か、行の終わりの CR-LF の前で終わ る。 (したがって文字列パラメータは空白を含まない) 。レスポンス内にパラメー タではないテキストがある場合、最後のパラメータからは空白で区切られていなけ ればならない。数字の後に続くテキストは、異なったサーバの実装では変更されて も良い。 3 桁の数字コードは、どのようなレスポンスが送られたかを判定するため に用いられるべきである。 この標準化仕様書の中で規定されていないレスポンスコードは、同様に標準化さ れていない installation-specific additional commands に用いても良い。これら は、上で規定した x8x にあてはまるよう選択されるべきである。 (デバッグは x9x のレスポンスコードによって、明示的に提供されることに注意されたい) 。規定さ れていないレスポンスコードを標準コマンド用に使用することは禁止されている。 我々はレスポンスパターン x9x をデバッグのために提供する。多くのデバッグ出 力が情報を与えるメッセージとして識別されてしまう可能性があるので、レスポン ス 190 から 199 までは様々なデバッグ出力のために利用されることを期待する。 この仕様書にはデバッグ出力に関する要求項目は存在しないが、接続された stream 上でデバッグの仕組みを提供するのであれば、これらのレスポンスコードを使用し なければならない。特定の実装のために適当であるならば、他の x9x コードをデ バッグのために用いてもよい。 (例えば、レスポンス 290 はリモートデバッグの要 求を通知するために用いられる) 。 2.4.3 一般的なレスポンス 以下は NNTP サーバから送られてくる一般的なレスポンスのリストである。これ らはあるコマンド特有のものではなく、接続、接続失敗、定常的でない状態の結果 として返される。 一般に 1xx は無視されるか、要求されたときに表示される。200 と 201 はポス トパーミッションに依存する NNTP サーバへの最初の接続時に送られる。400 は NNTP サーバがサービスを継続していないとき (例えば、オペレータの要求によって 落とされている) に表示される。 5xx は何らかの非定常的な理由によってオペレー ションが実行できなかったことを意味する。 100 ヘルプ テキスト 190-199 デバッグ出力 200 server ready - 投稿可 201 server ready - 投稿不可 400 サービス停止 500 コマンドが理解できない 501 コマンド文法エラー 502 アクセス制限を受けているか、パーミッションが与えられていない 503 プログラム障害 - コマンド実行されず 3. コマンドとレスポンスの詳細 以下のページは、NNTP サーバが理解するコマンドと、そのコマンドに対して返さ れるレスポンスに関する記述である。 NNTP サーバがコマンドを翻訳する際には大文字、小文字は無視されるが、わかり やすくするために各コマンドは大文字で記される。パラメータは全て小文字で記さ れる。[ ]で囲まれているものはオプションである。例えば、[GMT]は GMT という文 字が存在するかもしれないし、省略されているかもしれないことを示している。 このセクションに記述されている全てのコマンドは、全ての NNTP サーバにおい て実装されなければならない。 付加的なコマンドを追加することに関しては何も禁止事項は設けない。しかし、 そのような規定されていないコマンドは、この仕様書以後の revision との衝突を 避けるために、"X" という文字で始めることを強く推奨する。 実装者は、このような付加コマンドは規定されたステータスレスポンスコードを 再定義してはいけないということに気をつけて欲しい。標準的なコマンドに対して 規定されていない付加的なレスポンスを用いることもまた禁止されている。 3.1 ARTICLE、BODY、HEAD、STAT コマンド ARTICLE コマンド (と、関連する BODY、HEAD、STATコマンド) には 2 つの形式 があり、それぞれ回収されるべきアーティクルを異なる手法を用いて指定する。 ARTICLEコマンドの後に "< >" で囲まれた message-id が続く場合、1つめのコマン ド形式が用いられる。数字のパラメータが与えられるか、パラメータが無い場合、 2 つめのコマンド形式が実行されている。 このドキュメントの初めの方で書いたように、アーティクルのテキスト部分はテ キストのレスポンスとして返される。 HEAD と BODY コマンドは、ARTICLE コマンドと同一であるが、それぞれヘッダ行 だけを返したりアーティクルのテキスト部だけを返したりする部分が違う。 STAT コマンドは、テキストが何も返ってこないことを除けば、ARTICLE コマンド と同様である。グループ内のメッセージ番号によって (アーティクルを) 選択する 場合、STAT コマンドはテキストを送らずに、current article pointer をセットす る。返される通知レスポンスは、何らかの値を持つ message-id を含む。 message-id より (アーティクルを) 選択するために STAT コマンドを用いることは 有効ではあるが、その価値は疑わしい。message-id による選択は、"current article pointer" を変更しないからである。 3.1.1 ARTICLE (message-id による選択) ARTICLE 指定されたアーティクルのヘッダ、空行、テキスト (body) を順次表示する。 message-id は、アーティクルのヘッダ内で見ることのできる、メッセージの id で ある。クライアントは NEWNEWS コマンドの提供するリスト、他のアーティクルの references、他のコマンドのレスポンスから message-id を得ることが予想され る。 内部で保守されている "current article pointer" はこのコマンドでは「変更さ れない」ことに注意されたい。これは、今読まれているアーティクル内で参照され るアーティクルの表示を容易にするためであり、また 2 つ以上のニュースグループ に投稿しているかもしれないアーティクルの適切な順序と構成を決定する難しさに よるものである。 3.1.2 ARTICLE (番号による選択) ARTICLE [nnn] 指定されたアーティクルのヘッダ、空行、テキスト (body) を順次表示する。オ プショナルなパラメータ nnn は現在のニュースグループの current id で、ニュー スグループが選択された際に提供されるアーティクルのレンジから選択されなけれ ばならない。省略された場合には、現在のアーティクルであると仮定される。 正しいアーティクル番号が指定されると、内部的に保守されている "current article pointer" がこのコマンドによって指定される。 [以下はどちらの ARTICLE コマンド形式においても適用される]。current article number、message-id、テキストが続くことを示すレスポンスが返される。 返される message-id は、"< >" 内に識別情報の文字列を含むもので、これは アーティクルのヘッダから導き出される。アーティクルの Message-ID ヘッダ行 (RFC850 で要求されている) が、この情報の供給のために使われなければならな い。 Message-ID ヘッダ行がアーティクルから紛失している場合には、"< >"内には 0 が与えられる。 message-id フィールドは各アーティクルについて唯一のものであるから、複数投 稿されたり、複数のニュースグループにまたがって投稿されたアーティクルをス キップするためにニュース購読プログラムが用いることができる。 3.1.3 レスポンス 220 n アーティクル回収 - ヘッダとボディが続く (n = article number, = message-id) 221 n アーティクル回収 - ヘッダが続く 222 n アーティクル回収 - ボディが続く 223 n アーティクル回収 - リクエストされたテキストは分割されている 412 ニュースグループが選択されていない 420 current articleが選択されていない 423 このグループ内には、その番号のアーティクルが存在しない 430 そのアーティクルは存在しない 3.2 GROUP コマンド 3.2.1 GROUP GROUP ggg 必須パラメータ ggg は、選択すべきニュースグループの名前 (例えば "net.news" のような) である。有効なニュースグループのリストは、LISTコマンド より得ることができる。 選択が成功すると、そのニュースグループの最初と最後のアーティクル番号、そ のニュースグループ内に何個のアーティクルがファイルとして存在するかという評 価値が返される。評価値はある種の助けとなるものであるから正確でなくとも良い が、実際のアーティクルファイル数と同じか、それ以上の数でなければならない。 (実装によってはアーティクルファイルの数を実際に数えるし、別の実装では単に最 後のアーティクル番号から最初のアーティクル番号を減算することによって評価値 を算出するだろう) 。 このコマンドを用いて有効なニュースグループが選択されると、内部で保守され ている "current article pointer" がそのニュースグループの最初のアーティクル にセットされる。無効なグループが指定された場合には、前に選択したグループが 依然として有効となる。空のニュースグループが選択された場合には、"current article pointer" は不確定であり、使用されるべきではない。 ニュースグループ名は大文字、小文字に依存しないことに注意されたい。LIST コ マンドから得られるニュースグループ名にマッチするか、エラーになるか、どちら かの結果に終わらなければならない。 3.2.2 レスポンス 211 n f l s group selected (n = グループ内にあるアーティクル数の評価値 f = グループの最初のアーティクル番号 l = グループの最後のアーティクル晩後う s = グループ名) 411 no such news group 411 そのようなニュースグループは存在しない 3.3 HELP コマンド 3.3.1 HELP HELP サーバに実装されているコマンドの短い要約を提供する。ヘルプテキストは通常の テキスト表示がなされ、一行にピリオドしかない行で終わる。 3.3.2 レスポンス 100 help text follows 3.4 IHAVE コマンド 3.4.1 IHAVE IHAVE IHAVE コマンドは、クライアントが という id のアーティクルを 持っていることをサーバに知らせる。サーバがアーティクルのコピーを望む場合、 クライアントにそのアーティクル全体を送るよう指示するレスポンスが返される。 そのアーティクルを特に欲しないならば (既にそのコピーを持っている場合など)、 そのアーティクルは必要ない、というレスポンスが返される。 アーティクルの転送がリクエストされたなら、クライアントはそのアーティクル 全体すなわち、ヘッダとボディをサーバから指定されたテキスト転送の方法によっ て送る。その後、アーティクル転送が成功したか、失敗したかを示すレスポンスコー ドが返される。 この機能は、既に投稿されたアーティクルをホスト間で転送するために用いるこ とが意図されている点において、POST コマンドとは異なるものである。クライアン トがパーソナルなニュースリーダである場合、通常この機能は用いられない。特に、 この機能は受け取ったアーティクルが他のホストに転送されようとしていることを 示すために、サーバのニュース投稿プログラムを適切な設定 (フラグ、オプション 等) で発行する。 しかし、幾つかの更なる検査を経て、そのアーティクルが転送されるに不適切で あるとサーバが判断したなら、投稿、あるいは転送をしないこともある。コード 436、437 がそのような状況における適切なエラーコードである。 このような、後になってからのアーティクル拒否の原因として、不適切なニュー スグループや distribution、ディスク容量の問題やアーティクル長、ヘッダの偽造 などが考えられる。これらはサーバ側のニュースソフトウェアの代表的な制限であ り、NNTPサーバ自身には必須のものではない。 3.4.2 レスポンス 235 アーティクル転送 OK 335 転送されるべきアーティクルを転送中。.で終わる。 435 アーティクルは欲しない。転送無用 436 転送失敗。後ほど再試行されたし 437 アーティクル拒否。再送無用 実装に関するノート: あるホストではニュース投稿ソフトウェアは、そのアーティクルが投稿、転送に 適したものかどうかを直接判断できないかもしれないので、アーティクル転送成功 のレスポンスを返した後で、通知無しに (silently) そのアーティクルを削除する ことは許されている。したがって、コード 235 を返した後に受け取ったアーティク ルを廃棄することは許される。これは問題を完全に満足させる答えではない。おそ らくは、実装によってはそのような場合にはアーティクルを管理者にメール (して 判断を仰ぐ) するような実装が希望されるだろう。 3.5 LAST コマンド 3.5.1 LAST LAST 内部的に保守されている "current article pointer" が現在選択しているニュー スグループの一つ前のアーティクルにセットされる。既に最初のアーティクルにい る場合には、エラーメッセージが返され、現在のアーティクルは依然として選択さ れたままとなる。 内部的に保守される "current article pointer" は、このコマンドによってセッ トされる。 current article number と、message-id文字列を示すレスポンスが返される。 このコマンドは、レスポンスとしてテキストは返さない。 3.5.2 レスポンス 223 n a article retrieved - request text separately (n = アーティクル番号, a = 唯一のアーティクルID) 412 ニュースグループが選択されていない 420 current articleが選択されていない 422 これより前のアーティクルは存在しない 3.6 LIST コマンド 3.6.1 LIST LIST 有効なニュースグループと、関連した情報が返される。各ニュースグループの情 報は、一行ずつ、以下のようなフォーマットのテキストで送られる。 group last first p "group" はニュースグループ名である。"last" はそのニュースグループの内の現 在わかっている最も新しいアーティクル番号で、"first" は最初の番号である。 "p" は 'y' か 'n' で、そのニュースグループへの投稿が許されているか ('y')、 禁止されているか ('n') を示している。 "first" と "last" のフィールドは常に数字である。各数の頭に 0 が着くことも ある。"last" フィールドが "first" フィールドよりも小さいならば、そのニュー スグループにはアーティクルが存在しない。 ここで、ある特定のニュースグループについて、LIST コマンドの結果が投稿可に なっていたとしても、クライアントからの投稿が禁止されていることがあることに 注意してほしい。クライアントからの投稿禁止に関する説明については、POST コマ ンドの項を参照してほしい。幾つかのニュースグループは moderated や digest で あるため投稿できないので、各ニュースグループについて投稿フラグが存在する。 そのようなグループに投稿されたアーティクルは、それらを submitter に投稿する moderator にメールされなければならない。これは NNTP サーバによってクライア ントに与えられる投稿の許可とは独立したものである。 空のリスト (すなわち、このコマンドによって返ってくるのがピリオドだけの場 合) も有効なレスポンスであることに注意されたい。この場合、現在有効なニュー スグループが存在しないことを意味する。 3.6.2 レスポンス 215 list of newsgroups follows 3.7 NEWGROUPS コマンド 3.7.1 NEWGROUPS NEWGROUPS date time [GMT] [] "date and time" から作成されたニュースグループのリストが、LIST コマンドと 同じフォーマットでリスト出力される。 date は YYMMDD フォーマットの6桁の数である。ここで、YY は年号の最後の二 桁、MM は月 (必要に応じて頭に 0 がつく)、DD は日 (必要に応じて頭に 0 がn つ く) である。最も近い世紀は年の一部と仮定される。すなわち、86 は 1986 を指定 し、30 は 2030 を指定する。99 は 1999 を意味し、00 は 2000 を意味する。 time もまた指定されなければならない。HHMMSS フォーマットの6桁の数でなけれ ばならず、HH は時刻で 24時間表記する。MM は分で 00-59、SS は秒で 00-59 であ る。time は、"GMT" という文字が出てこない限りサーバの timezone 内の時刻と仮 定される。"GMT" の場合は time と date は経度 0 のものとして評価される。 オプショナルなパラメータ "distributions" は、"< >" で囲われた distribution group のリストである。これを指定すると、新しいニュースグループ の distribution 部 (例えば 'net.wombat' における 'net') がリストした distribution に一致するかどうか検査され、一致した新しいニュースグループだけ がリスト出力される。 2つ以上の distribution group をリストする場合には、 "< >"内でカンマで区切らなければならない。 空のリスト (すなわち、このコマンドによって返ってくるのがピリオドだけの場 合) も有効なレスポンスであることに注意されたい。この場合、現在新しいニュー スグループは存在しないことを意味する。 3.7.2 レスポンス 231 list of new newsgroups follows 3.8 NEWNEWS コマンド 3.8.1 NEWNEWS NEWNEWS newsgroups date time [GMT] [] 指定されたニュースグループについて、"date" 以降に投稿、受信したアーティク ルの message-id リストが出力される。リスト出力のフォーマットは、テキストを 送信するのと同じように一行に1つの message-id が出力される。一行にひとつだけ ピリオドがあり、CR-LF で終わる行でリストは終わる。 date と time は NEWGROUPS コマンドと同じフォーマットである。 "*" (アスタリスク) を含むニュースグループ名は、アーティクルの探索範囲を複 数あるいは全ニュースグループに拡大する。アスタリスクはニュースグループ名の 一部を拡張する。 (例えば、net.micro* は net.micro.wombat、net.micro.apple 等にマッチする) 。したがって、アスタリスクだけがニュースグループ名として与 えられたなら、全ニュースグループについて新しいニュースが探索される。 (アスタリスク "*" の拡張は一般的な置き換えであることに注意されたい。特に、 net.*.unix のような指定の場合、net.wombat.unix や net.whocares.unix のよう な名前を含んで拡張される) 。 逆に、与えられたニュースグループ名にアスタリスクが含まれていなければ、指 定されたニュースグループだけで新しいアーティクルが探索される。ニュースグルー プ名はサーバから返される利用可能なグループのリストから選択されなければなら ない。複数のニュースグループ名 ("*"を含む) をこのコマンド内で指定しても良 い。その場合、それらはカンマで区切られる。リスト内の最後のニュースグループ の後にカンマが現れるべきではない。[実装者はコマンド長の最大値が 512 キャラ クタであることに注意している]。 一致を否定するためにエクスクラメーション ("!") を用いても良い。これは、大 きなリストから特定のニュースグループだけを選択的に省くために使用することが できる。ニュースグループの指定 "net.*,mod.*,!mod.map.*" は、全ての net グ ループと全ての mod グループ、ただし mod.map.* ではないニュースグループ名が 一致する。使用する場合には、エクスクラメーションは与えられるニュースグルー プ名やパターンよりも前に現れなければならない。 オプショナルなパラメータ "distributions" は、"< >" で囲われた distribution group のリストである。これを指定すると、新しいニュースグループ の distribution 部分 (例えば 'net.wombat' における 'net') リストした distribution に一致するかどうか試験され、リストした distribution に属する ニュースグループが持っているアーティクルだけがリスト出力される。2つ以上の distribution group をリストする場合には、"< >"内でカンマで区切らなければな らない。 ニュースを配送するための IHAVE、NEWNEWS、NEWGROUPS コマンドの使用について は本ドキュメントの前の方で論じている。 空のリスト (すなわち、このコマンドによって返ってくるのがピリオドだけの場 合) も有効なレスポンスであることに注意されたい。この場合、現在新しいニュー スグループは存在しないことを意味する。 3.8.2 レスポンス 230 list of new articles by message-id follows 3.9 NEXT コマンド 3.9.1 NEXT NEXT 内部的に保守されている "current article pointer" が現在選択されている ニュースグループの次のアーティクルに進められる。現在のニュースグループ内に アーティクルが残っていない場合には、エラーが返され、現在選択されているアー ティクルはそのままとなる。 内部的に保守されている "current article pointer" はこのコマンドによって セットされる。 current article number、message-id 文字列が返される。このコマンドのレスポ ンスとしてテキストが返されることはない。 3.9.2 レスポンス 223 n a アーティクル回収 - リクエストされたテキストは分割されている (n = アーティクル番号, a = 唯一のアーティクル ID) 412 ニュースグループが選択されていない 420 current article が選択されていない 421 このグループ内に next article は存在しない 3.10 POST コマンド 3.10.1 POST POST 投稿が許可されていれば、投稿されるアーティクルを送信して良いことを示す コード 340 が返される。レスポンスコード 440 はインストール時になされたある 種の設定のために投稿が禁止されていることを意味する。 投稿許可ならば、アーティクルは RFC850 によって指定されたフォーマットで提 出され、必要とされる全てのヘッダ行を含んでいるべきである。アーティクルの ヘッダとボディが完全にクライアントからサーバに転送された後、投稿の試みが成 功したか失敗したかを示す更なるレスポンスコードが返される。 投稿されようとしているヘッダとメッセージのボディから構成されるテキスト は、クライアントによって、ニュースサーバからテキストを受け取るのと同じ仕組 で送信されるべきである。すなわち、一行にピリオド 1つだけがある場合にはテキ ストの終わりを意味し、オリジナルのテキスト内にピリオド 1つだけがある場合に は転送中にピリオド 2つに変換される。 NNTP サーバによるキャラクタのフィルタ、行数制限、その他受信したテキストに 対する何らかの処理は何もしないことになっている。サーバは投稿されるべく受信 したメッセージをそのまま通過させ、サーバにインストールされているニュース投 稿ソフトに受け渡すことが我々の意向であり、それ以外の処理はこの仕様書から独 立したものである。詳細については、RFC850 を参照されたい。 ほとんどの実装において、クライアントニュースプログラムはユーザがある種の テキストエディタを用いて自分のメッセージを準備し、それが成立した後にだけ投 稿のためにそのメッセージをサーバに転送するようにすることを許可したいであろ うから、クライアントプログラムはコネクションが最初に確立した際に最初に表示 されるメッセージに注意を払うべきである。このメッセージは、クライアントから の投稿が許可されているかどうかを示しているので、ユーザからのアクセスがリー ドオンリーである場合には警告するように使うことができる。これにより、ユーザ がメッセージを作成しても投稿が許可されないといった無駄な時間を費やすことを 予防できる。クライアントとホストが投稿できるかという判定と判定法はインス トールに依存し、この仕様書の範囲を外れる。 3.10.2 レスポンス 240 投稿されたアーティクルは OK だった 340 投稿すべきアーティクルを送信せよ。.で終われ。 440 投稿は許可されていない 441 投稿は失敗した (参考までに、最初の接続時に、以下に示すうちの1つが送られてくる。クライア ントプログラムは、それを見て一般的に投稿が許可されているかどうかを判定すべ きである) 200 server ready - posting allowed 201 server ready - no posting allowed 3.11 QUIT コマンド 3.11.1 QUIT QUIT サーバプロセスは QUIT コマンドを認めると、クライアントとの接続を閉じる。 これは、クライアントが処理を全て終えたことを NNTP サーバに示すために好んで 用いられる手法である。 クライアントが単純に接続を切断した場合 (もしくは接続がタイムアウトしたり 何らかの障害が発生した場合)、サーバはクライアントに対してサービスしようとす る試みを止める。 3.11.2 レスポンス 205 closing connection - goodbye! 3.12 SLAVE コマンド 3.12.1 SLAVE SLAVE サーバに対し、このクライアントの接続はユーザではなく、slave サーバへのも のであることを示す。 このコマンドは、単一ユーザから slave サーバまでの接続をそれぞれ分割する祭 に用いるよう意図されている。複数人にサービスしているようなクライアントから のリクエストには優先度が与えられるべきであることを示すために用いられる。 また、システムのロードレベルが一定の水準を超えた場合、どの接続を閉じるかを 決定するために用いられる。おそらく slave サーバに優先度が与えられるだろう。 実際には、このコマンドの使用は全く実装に依存しており、あるホストを別ホスト に切り替える。slave サーバに優先度を与えない NNTP サーバでも、このコマンド は理解され、認められなければならない。 3.12.2 レスポンス 202 slave status noted 4. やり取りのサンプル 以下は、仮定したセッションのニュースサーバとクライアントの間で期待される であろうやり取りの例である。表記 C: はクライアントプログラムからニュース サーバへのコマンド送信を示し、S: はサーバからのレスポンスをクライアントが受 け取ったことを意味する。 4.1 例 1 - NEXT を用いた相対的なアクセス S: (TCP/119 でリクエスト待ち) C: (TCP/119 での接続リクエスト) S: 200 wombatvax news server ready - posting ok (クライアントは現在のニュースグループリストを尋ねる) C: LIST S: 215 list of newsgroups follows S: net.wombats 00543 00501 y S: net.unix-wizards 10125 10011 y (中略) S: net.idiots 00100 00001 n S: . (クライアントはニュースグループを選択する) C: GROUP net.unix-wizards S: 211 104 10011 10125 net.unix-wizards group selected (10011 から 10125 まで 104 のアーティクルファイルがある) (クライアントは読むべきアーティクルを選択する) C: STAT 10110 S: 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics only (アーティクル10110が選択された。message-id は<23445@sdcsvax.ARPA>) (クライアントはヘッダを調べる) C: HEAD S: 221 10110 <23445@sdcsvax.ARPA> article retrieved - head follows (ヘッダのテキストがこの後に続く) S: . (クライアントはアーティクルのテキストボディを見ようとする) C: BODY S: 222 10110 <23445@sdcsvax.ARPA> article retrieved - body follows (テキストのボディが続く) S: . (クライアントはグループの次のアーティクルを選択する) C: NEXT S: 223 10113 <21495@nudebch.uucp> article retrieved - statistics only (アーティクル 10113 がグループ内の次のものである) (クライアントはセッションを終了する) C: QUIT S: 205 goodbye. 4.2 例 2 - ARTICLE を用いた、アーティクルへの絶対アクセス S: (TCP/119 でリクエスト待ち) C: (TCP/119 での接続リクエスト) S: 201 UCB-VAX netnews server ready -- no posting allowed C: GROUP msgs S: 211 103 402 504 msgs Your new group is msgs (402 から 504 まで、103 のアーティクルがある) C: ARTICLE 401 S: 423 No such article in this newsgroup C: ARTICLE 402 S: 220 402 <4105@ucbvax.ARPA> Article retrieved, text follows S: (アーティクルのヘッダとボディがこの後に続く) S: . C: HEAD 403 S: 221 403 <3108@mcvax.UUCP> Article retrieved, header follows S: (アーティクルのヘッダがこの後に続く) S: . C: QUIT S: 205 UCB-VAX news server closing connection. Goodbye. 4.3 NEWGROUPS コマンド S: (TCP/119 でリクエスト待ち) C: (TCP/119 での接続リクエスト) S: 200 Imaginary Institute News Server ready (posting ok) (クライアントは 1985年 4月 3日以降の新しいニュースグループを尋ねる) C: NEWGROUPS 850403 020000 S: 231 New newsgroups since 03/04/85 02:00:00 follow S: net.music.gdead S: net.games.sources S: . C: GROUP net.music.gdead S: 211 0 1 1 net.music.gdead Newsgroup selected (このニュースグループ内にはアーティクルが存在しない。 最初と最後のアーティクル番号は意味が無い) C: QUIT S: 205 Imaginary Institute news server ceasing service. Bye! 4.4 例 4 - 新しいアーティクルの投稿 S: (TCP/119 でリクエスト待ち) C: (TCP/119 での接続リクエスト) S: 200 BANZAIVAX news server ready, posting allowed. C: POST S: 340 Continue posting; Period on a line by itself to end C: (RFC850フォーマットのニュースアーティクルを転送する) C: . S: 240 Article posted successfully. C: QUIT S: 205 BANZAIVAX closing connection. Goodbye. 4.5 例 5 - オペレータのリクエストによる中断 S: (TCP/119 でリクエスト待ち) C: (TCP/119 での接続リクエスト) S: 201 genericvax news server ready, no posting allowed. (しばらくの間、通常のやりとりが行われ、あるニュースグループ が選択されたと仮定する) C: NEXT S: 223 1013 <5734@mcvax.UUCP> Article retrieved; text separate. C: HEAD C: 221 1013 <5734@mcvax.UUCP> Article retrieved; head follows. S: (アーティクルのヘッダが送られているが、その途中でオペレータの リクエストによって中断される。以下は、クライアントとの調整無し に発生する) S: (現在の行が CR-LF ペアで終了する) S: . S: 400 Connection closed by operator. Goodbye. S: (接続のクローズ) 4.6 例 6 - システム間でニュースを配送するためにニュースサーバを用いる S: (TCP/119 でリクエスト待ち) C: (TCP/119 での接続リクエスト) S: 201 Foobar NNTP server ready (no posting) (クライアントは 1995年 5月 15日 2:00am 以降の新しいニュースグループが あるかどうか問い合わせる) C: NEWGROUPS 850515 020000 S: 235 New newsgroups since 850515 follow S: net.fluff S: net.lint S: . (クライアントは 1995年 5月 15日 2:00am 以降の新しいアーティクルが あるかどうか問い合わせる) C: NEWNEWS * 850515 020000 S: 230 New news since 850515 020000 follows S: <1772@foo.UUCP> S: <87623@baz.UUCP> S: <17872@GOLD.CSNET> S: . (クライアントはアーティクル <1772@foo.UUCP> を問い合わせる) C: ARTICLE <1772@foo.UUCP> S: 220 <1772@foo.UUCP> All of article follows S: (全メッセージが送信される) S: . (クライアントはアーティクル <87623@baz.UUCP> を問い合わせる) C: ARTICLE <87623@baz.UUCP> S: 220 <87623@baz.UUCP> All of article follows S: (全メッセージが送信される) S: . (クライアントはアーティクル <17872@GOLD.CSNET> を問い合わせる) C: ARTICLE <17872@GOLD.CSNET> S: 220 <17872@GOLD.CSNET> All of article follows S: (全メッセージが送信される) S: . (クライアントは、最近受け取ったアーティクルを提示する) C: IHAVE <4105@ucbvax.ARPA> S: 435 Already seen that one, where you been? (クライアントは別のアーティクルを提示する) C: IHAVE <4106@ucbvax.ARPA> S: 335 News to me! to end. C: (アーティクル送信) C: . S: 235 Article transferred successfully. Thanks. (または) S: 436 Transfer failed. (クライアントはセッションを通じた全作業を完了する) C: QUIT S: 205 Foobar NNTP server bids you farewell. 4.7 コマンドとレスポンスの要約 以下は NNTP サーバに理解され、レスポンスが返されるコマンドである。 4.7.1 コマンド ARTICLE BODY GROUP HEAD HELP IHAVE LAST LIST NEWGROUPS NEWNEWS NEXT POST QUIT SLAVE STAT 4.7.2 レスポンス 100 help text follows 199 debug output 200 server ready - posting allowed 201 server ready - no posting allowed 202 slave status noted 205 closing connection - goodbye! 211 n f l s group selected 215 list of newsgroups follows 220 n article retrieved - head and body follow 221 n article retrieved - head follows 222 n article retrieved - body follows 223 n article retrieved - request text separately 230 list of new articles by message-id follows 231 list of new newsgroups follows 235 article transferred ok 240 article posted ok 335 send article to be transferred. End with . 340 send article to be posted. End with . 400 service discontinued 411 no such news group 412 no newsgroup has been selected 420 no current article has been selected 421 no next article in this group 422 no previous article in this group 423 no such article number in this group 430 no such article found 435 article not wanted - do not send it 436 transfer failed - try again later 437 article rejected - do not try again. 440 posting not allowed 441 posting failed 500 command not recognized 501 command syntax error 502 access restriction or permission denied 503 program fault - command not performed 4.8 USENET ニュースシステムに関する詳細 従来より 1200 bps の電話線によってリンクされている UNIX の世界において、 USENET ニュースシステムは中央ストレージの操作、ニュースの索引付け、回収、配 布の技術を発達させてきた。その根底にある転送メカニズム (UUCP) を別にすれ ば、USENET NEWS はニュースと掲示板サービスを UNIX を使用している登録者と ワールドワイドな別のホストに提供する効果的な手段である。USENET NEWS は、 RFC850 の中で詳細が論じられている。この仕組は、ほとんどのバージョンの UNIX と、他の多くの OS 上で動作する。また、習慣的に無料で配布される。 USENET は UNIX のスプールエリアをニュースアーティクルをファイル毎に保存す るために使用する。各アーティクルはヘッダテキストを含み、そこには sender の 識別情報や、組織情報、タイムスタンプ、電子メールのリプライパス、Subject、 newsgroups 等が含まれる。完全なニュースアーティクルを以下に再現する。詳細に ついては RFC850 を参照のこと。 Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site sdcsvax.UUCP Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek!honman From: honman@unitek.uucp (Man Wong) Newsgroups: net.unix-wizards Subject: foreground -> background ? Message-ID: <167@unitek.uucp> Date: 25 Sep 85 23:51:52 GMT Date-Received: 29 Sep 85 09:54:48 GMT Reply-To: honman@unitek.UUCP (Hon-Man Wong) Distribution: net.all Organization: Unitek Technologies Corporation Lines: 12 I have a process (C program) which generates a child and waits for it to return. What I would like to do is to be able to run the child process interactively for a while before kicking itself into the background so I can return to the parent process (while the child process is RUNNING in the background) . Can it be done? And if it can, how? Please reply by E-mail. Thanks in advance. Hon-Man Wong 5. References [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC-822, Department of Electrical Engineering, University of Delaware, August, 1982. [2] Horton, M., "Standard for Interchange of USENET Messages", RFC-850, USENET Project, June, 1983. [3] Postel, J., "Transmission Control Protocol- DARPA Internet Program Protocol Specification", RFC-793, USC/Information Sciences Institute, September, 1981. [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821, USC/Information Sciences Institute, August, 1982.