要約

  • RFC 3428は、SIPプロキシが一つのMESSAGE要求を複数の候補端末へ分岐させながら、送信側には最終応答を一つだけ返すことを認めた。
  • その応答からは分岐の有無も受信したユーザーエージェントの数も分からず、人が読んだことも証明できない。

この食い違いはプロトコルのモデルに含まれており、それ自体が障害を示すわけではない。RFC 3428は、単独で完結するページャー型メッセージをSIPで送るためにMESSAGEを追加した。この要求だけではSIPダイアログは始まらない。プロキシはSIPの規則で転送し、下流のプロキシは宛先ユーザーが使っているかもしれない複数端末へ要求を分岐できる。

すると、一つのトランザクションに二つの見え方が生じる。複数の分岐がメッセージを受け取って成功応答を返しても、プロキシは上流へ最終応答を一つだけ転送する。RFC 3428は、送信側のユーザーエージェントには分岐の有無を検出できず、応答が一つだから受信端末も一台だけだったと推定してはならない、と明記する。送信側が見た応答数は、宛先数ではない。

応答コードは重要だが、別の問いに答えている。通常の最終宛先からの200 OKなら、送信側はその宛先へ届いたと見なせる。しかし、利用者が見た・読んだという意味ではない。ユーザーエージェントは表示前に応答してもよく、応答後も表示義務はない。202 Acceptedはさらに限定的で、ゲートウェイや蓄積転送サーバーなどが受け付けたことを示すだけで、最終宛先への配送を確定しない。確認にはRFC 3428の範囲外の別手段が必要だ。

したがってトレースを調べると、送信側には一つのトランザクションと一つの最終応答しか見えず、下流ログには複数の成功分岐が残ることがある。これは矛盾ではない。逆に、上流の200が一つだけでも、配送が厳密に一回だったこと、受信端末の台数、利用者の注意までは証明できない。RFC 3428は規範上の可能性を示すのであり、特定サービスで実際に分岐が起きた証拠ではない。

このRFCが対象としたモデルも限定的だ。各MESSAGEは独立し、会話らしいまとまりはクライアントの画面や利用者の理解に委ねられる。明確な開始と終了を持つセッションモデルとは区別された。後年のRFC 8591はSIPメッセージにおけるS/MIMEの一部を更新・明確化したが、応答を既読証明に変えたわけでも、ここで扱う分岐の計数境界を変えたわけでもない。

出典：RFC 3428第2〜8節、SIPのルーティングとプロキシ動作についてRFC 3261、後年のS/MIME更新についてRFC 8591。全資料：