要約

  • RFC 5118 は RFC 3261 の ABNF から余分なコロンを含む IPv6 reference が導かれ得ることを示し、receiver は robustness のため受理しても、forwarder は余分なコロンを除いて送るべきだとした。
  • 同じ文書には、port を IPv6 の角括弧内に置いたため、syntax は通るのに宛先の意味が変わる例もある。parse 成功は意図保存の証明ではない。
  • test corpus は Informational で非規範的、かつ網羅的ではない。特定 build の入力処理を示しても、SIP 全体の適合、route、dialog、media、利用者結果までは証明しない。

受信側が一つ余分なコロンを無視し、構造を取り出せたとする。その時点で障害を回避したように見える。しかし同じ byte をそのまま次の proxy へ渡せば、次の parser は拒否するかもしれない。寛容さは end-to-end の事実ではなく、一つの hop の判断である。

RFC 5118 はこの違いを明示した。RFC 3261 の IPv6address の組み合わせから、埋め込み IPv4 の直前に余分なコロンを持つ形が生成され得る。受信実装は robust に受理できる。だが message を serialize して転送するなら、次の実装を助けるため余分なコロンを取り除く。

入力の受理と出力の custody

この規則には二つの receipt がある。第一は「この build が入力からどの component を得たか」。第二は「forwarder がどの byte を次へ送ったか」。一方だけでは interoperability を説明できない。

silent normalization は便利だが、原文を失うと誰が差分を作ったか分からない。元の message、適用した例外、parse tree、出力 message を対で保存する必要がある。正規化後の一行だけを log に残すと、障害時には sender の問題と intermediary の修正を区別できない。

逆に、strict mode という名前だけで既知の互換入力を全て拒否するのも不十分である。RFC 5118 は Via の received について、角括弧あり／なしの両方を受け入れ、送信時は括弧なしにするという限定規則を示した。例外は field と方向を持つ。

正しく parse したまま宛先を間違える

より危険なのは、修復を必要としないほど文法的に正しい入力である。

sip:[2001:db8::10:5070]

もし sender が host 2001:db8::10 と port 5070 を意図したなら、右角括弧の位置が遅い。parser は 5070 を address の最後の 16-bit group として受け取る。verified erratum が訂正した通り、これは最後の octet ではなく octet pair である。

意図した形は sip:[2001:db8::10]:5070 である。二つとも syntax として成立し得るが、component tree と宛先は異なる。parser に sender の頭の中は見えない。test harness は期待 host と port を入力とは独立して持たなければならない。

同じ corpus には、URI の IPv6 literal に必要な角括弧を欠き、400 を返すべき例もある。無効、robustness により限定受理、valid だが意図と不一致という三状態を、pass/fail の二値に落としてはならない。

Header と SDP では同じ address の形が違う

SIP URI の IPv6 literal は角括弧を使う。SDP の connection address は使わない。RFC 5118 は IPv4 と IPv6 が混在する Via、audio と video が別の address family を使う SDP、IPv4-mapped IPv6 が signaling と SDP に現れる例も用意した。

文字列だけを見て全ての IPv6 を同じ形に直す middleware は、ある layer を直して別の layer を壊す。context を保持しない一元的な normalization は、見た目をそろえる代わりに意味を消す。

この境界は運用設計にも通じる。共有 parser は syntax の最小共通層を扱えるが、route policy や application intent まで所有しない。誰がどの結果の downside を負うかに応じて、決定と証拠を分離すべきである。

RFC の折り返しは wire の改行ではない

長い SIP field を RFC の紙面に載せると visual line break が生じる。RFC 5118 は RFC 4475 の allOneLine を使い、どのように連結するかを指定した。さらに bit-exact message archive を内蔵する。

画面から copy した fixture は、space、newline、Content-Length が変わっている可能性がある。test の最初の control は message hash、抽出手段、byte count である。parser の前に harness が入力を整えたなら、その変換も記録しなければならない。

同じ hash の fixture を使っても、結果は build、library、flag、locale、transport context に依存する。RFC 5118 自身が Informational、SIP に対して非規範的、非網羅的だと宣言している。pass 率を製品認証へ膨らませてはならない。

Parse tree の外側

component が正しくても、DNS や route policy が別の next hop を選ぶことがある。transaction response が返らないこともある。dialog ができても SDP の media が届かないことがある。media packet があっても利用者の目的を満たさないことがある。

反対に、一度の成功は parser 差異を否定しない。alternate contact や upstream repair が差を隠し、topology change で再出現する。

従って evidence は順番に残す。exact bytes、grammar production、parse tree、独立した intent、forwarded bytes、next hop、transaction、dialog、media、user outcome。前の receipt は後ろの authority ではない。

Robustness を例外台帳にする

RFC 5118 の実務的価値は、曖昧な「寛容さ」を具体的な rule に変えた点にある。field、入力形、期待 component、出力形が分かる。これなら owner、利用数、peer、導入理由、廃止条件を管理できる。

例外が不可視なら実装の癖になる。可視なら interoperability のための局所判断になる。running code を尊重するとは、何でも受け入れることではない。現実の入力と結果を残し、最小の修復だけに権限を与えることである。

出典