要約

  • IESGは2026年9月3日、Safe-IOCの独立投稿がIETF作業と競合しないと結論づけた。RFC 5742に基づくこの判断は、技術的承認、IETF合意、RFC発行のいずれでもない。
  • 第13版は正規化と逆変換を定める。しかし値が安全なのは、各受け手が非実行の出力先を守る間だけだ。管理対象は括弧ではなく、復元後に誰が何を動かせるかである。

IETFの告知はconflict reviewの結論を伝えた。RFC 5742におけるIESGの役割は、Independent Streamの文書がIETFの標準化作業と衝突するかを調べることだ。衝突がなければ、技術的価値と発行判断は独立投稿側に残る。文書ページも、個人Internet-Draft、Independent Submission、Informational予定であり、IETFまたはWGの承認ではないと明示する。第13版は9月4日付で、確認時点ではRFC番号を持たない。

RFC Editorの説明によれば、独立流のRFCはコミュニティ合意を必要とせず、標準やベストプラクティスでもない。「競合なし」を「安全性認証」と読み替えると、手続上の一つの記録が全実装の保証へ膨張してしまう。

第13版本文は、ばらばらだったデファング表記を一つの順序へ寄せる。schemeを囲み、userinfoとhostの構造的区切りを変え、既に変換済みのtokenは不透明として再処理しない。したがって同じ処理を繰り返しても括弧は増えず、変換は冪等になる。

ただし冪等性は逆変換後の安全性を証明しない。復元機能は実際に使えるURIやアドレスを再生成する。草案は、出力を自動解釈できないバッファーだけに書き、ブラウザーのプレビュー、稼働中の文書、リッチテキスト編集、アドレスバーなどで復元しないよう要求する。冒頭のコンソールは文字列の試験とネットワーク操作を同じボタンに結び付けた点で失敗した。

RFC 3986の予約文字と非予約文字の区別も重要だ。host内のパーセント符号化された点は変換前に正規化できる一方、符号化された予約区切りは意味を変えるため保存しなければならない。復元結果は意味的に等しくても、元と同一バイトとは限らない。元データを捨てれば、後日の証拠照合は弱くなる。

リダイレクト先がqueryの中に入る場合、単純な全置換は通用しない。path、query、fragmentの句読点を一律に変えれば、ファイル名や通常データまで壊す。草案は文法で認識した入れ子の指標だけを再帰処理する。つまり実装ごとの分類器が権限面になる。

部分的な変換は、未処理より危うい安心感を作る。有効なschemeを残してhostの点だけを囲む形式も、その逆も正規形ではない。従来の hxxp と hxxps はscheme位置に現れる。IANA URI SchemesレジストリとRFC 7595が示す暫定登録は、解決やアクセスの許可ではない。

表記は指標の品質も証明しない。RFC 9424はIoCを発見、評価、共有、配備、検知、対応、寿命終了の連鎖として扱う。アドレスは古くなり、正当用途と共有され、誤って帰属され得る。RFC 7970、STIX 2.1、TAXII 2.1の構造化された文脈は、Safe-IOCの句読点では置き換えられない。受信、遮断設定、観測、対応は別の証跡だ。

試験にはRFC 2606の予約名を使い、実在する悪性サイトを仮定しない。Running-Code Primacyは実際のコンソールとプレビューを試す規律を与える。Minimum Initial Specification, Localized Future Decision, and Voluntary Adoptionは最小表記を共有しつつ復元権限をローカルに残す。On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostileは正規形という記号と、発生したアクセスという現実を分ける。