要約

  • RFC 1312 は TCP/UDP 上の実験的な短文メッセージサービスを定義し、受信者、受信端末、送信者、cookie、署名などの欄を持たせたが、欄は在席する人を証明しない。
  • TCP の + は、何らかのユーザーまたは端末への配送成功を意味する一方、RFC はそれがローカル配送サービスの起動だけを示す場合があると限定する。
  • 仕様は、ローカル配送、ウィンドウ表示、ポップアップを閉じることでの既読確認のどれに応答を結び付けるかを定めない。肯定応答は既読の証拠ではない。

分析

宛先欄は人の所在を確定しない

RFC 1312 のメッセージには、改訂番号に続いて null 終端の受信者、受信端末、本文、送信者、送信端末、cookie、署名が並ぶ。ここで受信者と端末は、配送を試みるための手掛かりであって、人の居場所の観測値ではない。

受信者が空なら、宛先システムの任意のユーザーへ配送してよい。端末が空なら「正しい」端末をシステムが選ぶが、それはシステム依存である。端末欄の * は全端末を含意し、双方が空なら、オペレーターか管理者に見られそうな場所として定義された console に書くべきとされる。どの場合も、選択を実施するのは受信側の局所的な仕組みである。

したがって、メッセージがユーザー名や端末名を持っていても、特定の人がそこにいたこと、画面が表示されたこと、内容が意識されたことは分からない。配送指示を、人物に関する完了報告へ格上げしてはならない。

+ が知らせるのはサーバーの到達点

TCP ベースのサービスでは、接続後にメッセージを送り、サーバーは + または を返す。+ はメッセージが何らかのユーザーまたは端末へ成功裏に配送されたことを、 はどの端末にも配送されなかったことを意味する。ここまではサーバーが記録できる操作上の区別である。

しかし RFC は、これを真の end-to-end semantics と同一視できないとする。肯定応答は、Message Send サーバーがローカル配送サービスを成功裏に呼び出したことだけを表すかもしれない。ローカルサービスへの引き渡し、ウィンドウシステムによる表示、利用者がポップアップを閉じて読んだと確認することのどれに応答が対応するか、仕様は定めていない。

この留保により + は弱い記号になるのではない。正しい対象について強い記録になる。ただし、表示された、端末に人がいた、読まれた、理解された、返答があったという各主張には、別の観測が必要である。一文字の応答が、その後の社会的事実を代筆することはない。

UDP の無応答と cookie は別の仕事を持つ

UDP のサービスでは、回答データグラムを返せる。特定ユーザー宛てで成功した場合は肯定応答を返すべきだが、任意ユーザー宛て、または配送不能の場合には返答しない。RFC は、ブロードキャストに全サーバーが応答する事態を避けるための方針だと説明する。従って沈黙は、配送失敗という一意の意味を持たない。

cookie と送信元 UDP ポートの組は、サーバーが重複メッセージを識別する助けとなる。クライアントは到達の可能性を上げるため同じメッセージを複数回送れ、サーバーは重複を捨てられる。これは重複処理の境界であり、最初のコピーが画面に届いたこと、適切な人が見たこと、通信が完結したことの証明ではない。

署名らしい欄も本人性を完成しない

SIGNATURE が空であれば送信者の本人性は検証できない。空でなくても、RFC は安全トークンの大文字小文字を区別しないテキスト符号化として扱うだけで、符号化も解釈も定義しない。また表示対象となる本文をフィルタリングするよう求め、許可なく端末へ書くことや制御文字の危険を別の問題として扱う。

送信者文字列、送信元アドレス、署名欄、局所的配送、表示、既読は互いに異なる証拠である。仕様が分けたものを、運用上の緑の表示で一つにしてはならない。

小さな確認を小さく保つ

RFC 1312 は 1992 年の Experimental RFC であり、現代の通知システムの挙動を証明しない。それでも、確認がどこまでを確認したのかを正確に名付ける習慣を残す。ローカル配送サービスを呼び出したという事実は有用である。画面表示、注意、既読、同意はそこから独立した事実である。

この順序を守れば、サービスの受領書を人の受領書に作り替えることなく、両者を検証可能に保てる。

出典

RFC 1312 は 1992 年の実験的仕様であり、実在の受信者、表示、既読、同意、本人性、配備または結果を立証しない。