要約

  • 初期NNTPは配信・検索・取得・投稿を一つのプロトコルに収めたが、各接続がすべての仕事を許されるわけではなかった。
  • MODE READERはtransit modeからreading modeへの移行要求であり、移行後のCAPABILITIESが現在使える命令の証拠になった。
  • この切替は状態を初期化し得るうえ、pipeline化も反復もできない。閲覧役割は投稿権、認証、暗号化を意味しない。

ポート番号では説明できない変化

クライアントが接続直後に能力を尋ねると、IHAVEとMODE-READERが返る。IHAVEは別のニュースサーバーへ記事を提示するための命令で、まだREADERはない。そこでMODE READERを一度送る。成功後に能力を取り直すと、今度はREADERやNEWNEWSが現れ、IHAVEは消えてよい。

ネットワーク上の相手は変わっていない。変わったのは、この会話でサーバーが引き受ける仕事である。ホスト名やポートを恒久的な権限表として扱うクライアントは、古い役割の知識で新しい状態を操作することになる。

RFC 977は1986年、NNTPの範囲をニュース記事のdistribution、inquiry、retrieval、postingとした。利用者は中央の保存先から必要な記事を読み、協力するホスト同士は記事を交換してローカルに保持できた。一つの文法が人とデータベース、サーバーとサーバーの双方を結んでいた。

実装が先に役割を分けた

RFC 2980は、すでに使われていた拡張を記録した文書である。そこではMODE READERがINNで初めて提供され、クライアントがnews reading clientであると示し、サーバーがreader commands向けに再構成する材料になったと説明される。

したがって、この命令は抽象的なモード設計から始まったのではない。一つのlistenerの後ろでfeed処理と閲覧処理が分かれたため、クライアント側にも境界を越える共通表現が必要になった。

同文書は、広く実装されなかったRFC 977のSLAVEとも対比する。ただし両者を一対の反対モードと読むべきではない。確認できる歴史は、読者として扱ってほしいという実運用上の要求が残り、標準化されたということだ。

能力は製品ではなく状態に属する

RFC 3977はreading server、transit server、mode-switching serverを区別した。切替可能なサーバーは接続直後のtransit modeでMODE-READERを広告し、READERを広告しない。移行後は逆にMODE-READERを外し、READERを示す。以前のIHAVEを残す義務もない。

ここでCAPABILITIESは静的な製品仕様ではなくなる。RFCは一覧が現在の状態で利用可能な能力を正確に反映するよう求める。認証やTLS、モード変更によって同一セッション内でも答えは変わり得る。

IANAのNNTP ParametersはMODE-READER、READER、IHAVE、STREAMINGの意味を登録している。これは語彙の調整であり、特定サーバーの現在の提供状況を保証する台帳ではない。

切替点をpipelineに埋め込めない理由

RFC 3977はMODE READERをpipeline化してはならないとする。結果を待たずGROUPやNEXTまで流せば、サーバーはどの役割で後続バイトを解釈するのか、クライアントはどの応答がどの命令に対応するのかを見失う。

命令は一セッションで一度だけであり、securityまたはprivacy commandの後にも送れない。さらにサーバーは、切替前に状態を接続直後まで戻してよい。TCPが続いているからといって、選択中のgroup、current article、認証に関する想定が保存されるとは限らない。

これは単なる実装上の注意ではない。役割変更はparserと権限の境界であり、前の状態の命令を新しい状態へ滑り込ませないための同期点である。

読者になっても投稿者とは限らない

成功応答には200と201がある。前者は投稿可、後者は投稿不可だが、どちらもreading modeへの移行を示す。閲覧サービスが恒久的に使えない場合は502を返し、サーバーは接続を閉じる。

閲覧への入場、記事を追加する権限、サービスそのものの不在は異なる判断である。readerという役割からpublisherの権限を推測してはいけない。現在のPOST capabilityなど、より細かな証拠をその時点で読む必要がある。

セキュリティは別の遷移である

RFC 3977の例では、reading modeに入った後だけSTARTTLSが見える場合さえある。RFC 4642はTLSを、RFC 4643は認証を別々に定義する。成功すれば、それぞれ能力一覧を再び変え得る。

MODE READER自体は本人性も機密性も与えない。逆にTLSや認証だけでreader commandsが有効になるわけでもない。RFC 4644のSTREAMINGはfeed転送の能力である。役割、身元、保護、変更権限を一つのフラグへ潰さないことが、最小権限を保つ。

残ったのはモードではなく境界の作法

単一入口で複数の仕事を扱えば、発見は簡単になる一方、状態依存の誤りが増える。別ポートや別プロセスの方がよい場合もある。RFC群は現在の構成比を示さず、唯一の配置を命じてもいない。

それでもMODE READERの設計は長く使える原則を残した。仕事が変わるなら、移行要求、結果、更新された能力、失われ得る状態をプロトコル上に出す。同じsocketが生きている事実に、古い権限を延命させない。

出典と限界

これらは仕様、標準化の経緯、登録語彙を示すが、現在の普及率、実装内部、トラフィック量、個別運用者の方針を測らない。本稿も登録を利用実績とみなさず、MODE READERを認証・暗号化・投稿許可とは扱わない。