要約

  • RFC 3529 では、通常の XML-RPC 結果だけでなく fault も BEEP RPY に入った。XML-RPC fault のために BEEP ERR を使うことはなかった。
  • 名前解決、チャネルの ready、通信の秘匿、相手認証は、それぞれ方法の認可、実行成功、永続的な外部効果とは別の証拠だった。

この仕様を読む鍵は、エラーを一つの箱に集めなかった点にある。BEEP の一対一交換では、開始側が MSG を送り、相手が RPY を返す。RFC 3529 は XML-RPC の methodCall と methodResponse をその形に載せたが、XML-RPC fault が生じても外側を ERR に変えなかった。

したがって RPY は、応答が要求に対応して返されたという BEEP 上の肯定だった。手続きが正常値を返したかどうかは XML 文書の内側で決まった。外側のフレームだけを見る監視は、明示的に報告された失敗を成功件数へ足してしまう。

呼び出し前にも別の状態機械があった。profile は boot から始まり、開始側が資源を含む bootmsg を送った。相手が資源を認識して bootrpy を返すと ready へ進んだ。形式不良または未知の資源なら error や ERR が返り、状態は変わらない。ここで失敗したのは profile の初期化であり、XML-RPC 方法の実行ではない。

逆に bootrpy も広い保証ではなかった。そのチャネルが指定資源に結び付いたことは示すが、任意の方法名が存在すること、引数が妥当であること、呼び出し主体に権限があること、処理が保存されることまでは示さない。ready は実行可能性への入口であって、実行結果ではない。

URI はさらに外側の段階を組み立てた。xmlrpc.beep の authority は BEEP の serverName へ、path は起動資源へ対応した。ポートが省略されれば _xmlrpc-beep._tcp の SRV 探索を行い、適切な SRV がなければアドレス解決と割当済みポートを使った。DNS が正しく目的地を選んでも、待受プロセス、対応 profile、認可、結果のいずれも証明しない。

xmlrpc.beeps は同じ探索規則を使いながら、XML-RPC profile を開始する前に BEEP session を秘匿用に調整するよう求めた。TLS を使う場合、URI の authority と証明書のサーバー識別子を照合した。これは「保護された通信でどの相手に接続したか」を強くするが、「その相手が方法を許可したか」「要求された変更が永続化したか」には答えない。

2003 年という時代は必須機構にも表れている。認証には DIGEST-MD5、秘匿には RSA と 3DES を使う TLS profile が挙げられた。その後の SASL と TLS の文書は、古い枠組みや方式の位置付けを変えた。RFC 3529 の暗号選択を現在の推奨として再利用するのではなく、当時の境界設計として扱う必要がある。

IANA 登録も実行証明ではない。BEEP profile、xmlrpc.beep と xmlrpc.beeps、TCP 602 の xmlrpc-beep service が共通名を与えた。登録表から分かるのは名前と参照先であり、実装、稼働、トラフィック、方法成功ではない。記号の持続とサービスの持続は同じではない。

BEEP core は一つの session 上で profile と channel を管理し、TCP mapping は共有接続上の流量を扱った。SOAP over BEEP も近い時期に同様の組合せを試した。再利用できる下層は便利だったが、結果の所有者を曖昧にしてよい理由にはならない。むしろ、どの層の肯定かをログに残す必要が増えた。

一回の呼び出しを復元するには、元の authority、選ばれたアドレス、相手識別、channel、資源、message number、RPY か ERR か、そして methodResponse が通常値か fault かを結ぶ。状態変更なら、アプリケーションの操作 ID、版、監査記録、再読込も必要になる。

再試行はこの差を実害へ変える。応答前の切断では実行済みか判断できない。fault を含む RPY は否定判定を示すが、方法仕様が保証しない限り、部分的副作用が絶対にないとは言えない。外側だけを成功と数えるのも、タイムアウトだけを未実行と決めるのも危険である。

RFC 3529 は Experimental だった。普及を証明する文書ではない。しかし、成功という語が層ごとに異なることを鮮明に残した。プロトコルは失敗判定を正しく配送できる。その配送成功を、処理成功へ読み替えてはならない。

Sources