要約
- RFC 1861は、コマンドの受理、端末のオンライン状態、キュー、端末への配送、利用者の閲覧、返信、終了をそれぞれ異なる証拠として表した。
ACKReadは閲覧確認を返信から切り離し、Message_Tag、Pass_Code、MSTAtus、増加するシーケンス番号によって接続終了後も変化を追えるようにした。- ただし文書はInformationalであり、セキュリティは論じられず、保存やタイムアウトには運用者の裁量が残り、独立プロトコルと既存メール基盤のどちらを使うかという議論も出版によって決着したわけではない。
人間の時間を回線から切り離す
端末までの配送は数秒で終わっても、受信者がポケットから機器を取り出すまでには十分、十分以上、あるいは一晩かかることがある。返信はさらに遅れるかもしれない。人は故障していなくても、ネットワークのタイムアウトに合わせて行動しない。
RFC 1861 は、この当たり前の事実をプロトコルの寿命に反映した。文書は、ホストから加入者までの配送と受領確認は比較的予測しやすい一方、加入者が実際に端末を取り出し、読み、応答する時刻は予測できないと述べる。その間ずっと電話回線を維持すれば、特に着信側が負担する番号では費用が膨らむ。そこで状態を接続から独立させ、後から問い合わせられるようにした。
これは単に非同期通信を採用したという話ではない。待っている対象を言葉で区別した点が重要だった。無線配送を待っているのか、閲覧を待っているのか、返信を待っているのか。それぞれの遅延は別の当事者と別の対処を持つ。
一方向の橋に戻り道が加わった
SNPPの前史は短い。1994年1月の RFC 1568 が初期版を示し、同年7月の RFC 1645 がVersion 2として置き換えた。RFC 1861は1995年10月に公開され、RFC 1645を廃止扱いにして、双方向端末のためのLevel 3を追加した。
従来のSNPPは、インターネット上のクライアントとTAP/IXOページング端末の間に置かれる薄い橋だった。利用者は宛先と本文を渡し、ゲートウェイが古い制御文字や端末側の手続きを引き受ける。Level 1の代表的なやり取りでは、PAGE、MESS、SENDにそれぞれ肯定応答が返る。
双方向端末は、同じ橋に戻り道を作った。2WAYが一件の取引を始め、SENDが送信段階を終える。その後もクライアントはMSTAtusで記録を参照できる。返信が一人の受信者に結びつくため、Level 3は本質的に一端末中心だった。多数宛ての送信効率より、誰の状態を追っているのかを曖昧にしないことが優先された。
250は配送証明ではない
SNPPの一般的な250は、サーバーがコマンドを正常に処理したことを示す。ページャーIDや本文、オプションを受け付けたという、ゲートウェイ上の事実である。無線網を越えたことや、端末に表示されたことは含まれない。
双方向のPAGErでは、次の境界が明示された。850は端末がオンラインで取引を受け付けたこと、950はオフラインだが後の配送のためキューに入れること、750はオフラインで取引を拒否することを示す。
同じコマンドへの三つの返答は、運用上まったく異なる。850なら現在の経路を続けられる。950なら遅延を許すかを考えなければならない。750なら別の連絡手段に切り替えられる。これらを一つの「送信成功」に丸めれば、表示は簡単になるが、判断材料は失われる。
終了までの距離をコードにした
RFC 1861は、双方向取引の状態を最終性によって四群に整理した。86xは最初の配送が済み、要求された動作を待っている。87xは中間処理が進んだが、まだ閉じていない。88xは最終状態である。96xはキューにある。
SENDは、閲覧確認待ちなら860、返信待ちなら861、返信不要の配送完了なら880、配送待ちのキューなら960を返しうる。後のMSTAtusでは、配送・閲覧済みで返信待ちの870、配送・閲覧済みの881、選択式返信の888、自由文返信の889へ進むことがある。780は配送前に期限切れになったことを残す。
88xを受け取れば、要求された部分は処理され、以後状態は変わらない。文書はこの線を明言した。したがって860を完了として表示するクライアントは、プロトコルが保った未完了性を自ら消している。960を配送済みに見せれば、将来の試行を現在の成果へすり替えている。
コードの価値は数字の権威ではない。どこまで観測が進み、何がまだ開いているかを狭く述べることにある。
閲覧は返信から独立していた
ACKRead 1は、受信者が受け取ったメッセージを実際に見たとき、端末から通知を返すよう求める。仕様は、この機能が実際の返信とは独立していると明記した。
端末に届いても人が見ていないことがある。見ても答えないことがある。答えられない事情や、答える権限がない場合もある。この違いを残せば、無応答を誤って未配送と判断することも、閲覧を同意とみなすことも避けられる。
返信形式はRTYPeで選べた。返信なし、はい・いいえ、事業者が用意した簡易返信、メッセージごとの選択肢、自由文である。MCResponseは個別の選択肢を設定した。888が返れば、その選択コードが戻ったことは分かる。しかし、内容を十分理解したこと、自由な意思であったこと、勤務先を拘束する権限があったことまでは分からない。
通信の証跡は精密になった。権限そのものが増えたわけではない。
キューに入れない権利
オフラインの端末へ後で配送する仕組みは便利だが、緊急情報では危険にもなる。十分後に届く障害通知は、配送率には貢献しても復旧には寄与しない。待機中であることが見えなければ、送信者は別経路を使う機会を失う。
NOQUEUEはPAGErより前に指定し、その取引での待機を禁止した。端末がオンラインでなければ、サーバーは750系で拒否する。メッセージの時間価値を知るクライアントが、遅延を受け入れるかどうかを決められた。
EXPTagはキューにあるメッセージの期限を変更した。期限までに届けられなければメッセージを削除し、状態を未配送として更新する。標準の保存期間やタグの失効時期はベンダー依存だったため、共通仕様があらゆる運用を一律化したわけではない。
最終状態を読み終えた後にはKTAGでタグを消せた。記録は障害調査に必要だが、閲覧時刻や返信を際限なく蓄える理由にはならない。保持期間と削除権限は、配送機能とは別の責任面である。
状態票を開く二つの値
双方向のSENDが成功すると、Message_TagとPass_Codeが返る。仕様はタグを記録の所在を示す番号、パスコードを状態確認を許可する無作為なPINとして説明した。MSTAtusは両者を使って現在値を取得する。
記録には、状態が変わるたび増えるSequenceと日時も含まれた。クライアントは、同じ配送状態を再読しただけなのか、新しい閲覧や返信が発生したのかを区別できる。ただし、これは改ざん不能な台帳や完全な時刻同期を保証する記述ではない。
さらに、RFCのSecurity Considerationsは「このメモではセキュリティ問題を論じない」とするだけである。PINという名前から、暗号化、強い本人確認、推測耐性、権限分離、安全な保存を補ってはならない。精密な閲覧・返信記録は価値が高い分、漏えい時の損害も大きい。仕様にない保護をあることにするのは、史料を豊かにするのではなく、境界を壊す。
場所を告げずに存在を答える
PINGは端末の位置や状態を尋ねる機能だった。位置情報の機微性を認め、加入者は実際の場所の代わりに、端末はシステム上にあるが位置情報は提供しないという一般応答を選べた。RFCはこれをACLU modeと呼び、821を割り当てた。
事業者が位置を知ることと、照会者が位置を受け取る権利を持つことは別である。821は、接続可能性を全否定せずに開示範囲を狭めた。
一方、加入者の選択をどう確認するか、誰が例外を決めるか、位置履歴をどう守るかは書かれていない。一つの応答を抑制する仕組みは、包括的なプライバシー制度ではない。ここでもプロトコルは局所的な制御を示し、サービス全体の統治者を演じなかった。
別プロトコルは唯一の答えではなかった
文書には、以前の版を検討したIESGメンバーと「822 Extensions」ワーキンググループが、既存メール基盤を使う案を好んだと記録されている。広く配備された電子メールを利用する利点があり、新しいプロトコルの導入費用は高い。慎重な設定だけで「ただちに届けるか失敗する」という要件を満たせるという意見も、ページング固有機能をSMTP拡張にする案もあった。
著者は反対意見を認めつつ、TAP/IXOとその後継の詳細を利用者やメール方式から隔離する価値があると論じた。メールからSNPPへのゲートウェイを作ることもできる。争点は、必要な複雑性をどこに置き、既存設備と新しい機能の費用を誰が負うかだった。
RFC Editorの情報ページ が示す区分はInformationalである。公開番号は議論と設計を保存したが、普遍的な採用やIETFによる強制を意味しない。この区別もまた、文書が教える状態境界の一つである。
記録は自分の観測面にとどまる
ゲートウェイはコマンド処理を知る。ページング事業者はキューと無線配送を知る。端末は受信と閲覧を報告できる。戻り経路は選択や文章を運ぶ。クライアントは状態を並べ、終了条件を判断する。完全な現実を単独で所有する者はいない。
RFC 1861は、その分散を曖昧さとして隠さなかった。端末には届いたが人はまだ見ていない、という二つの事実を同時に成立させた。閲覧後も返信待ちを残し、期限切れを配送成功に混ぜなかった。
現代のシステムにも同じ問いを向けられる。どの場所に届いたのか。誰が観測したのか。まだ開いている要求は何か。誰が記録を書き換えられ、誤りの損失を誰が負うのか。記録は狭く答えるほど信頼できる。技術的な途中経過から、人の注意、同意、権限まで勝手に引き受けた瞬間、記録は証拠ではなく支配の道具になる。
出典
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
