Summary

  • RFC 9948は、2026年4月1日にIndependent StreamからInformationalとして公開された真正なRFCである。同時に、Status of This Memoは、Standards Track仕様ではなく、RFC Editorが実装・配備価値を判断せず、Internet Standardの候補にもならないと明記する。
  • Raised Eyebrow、Frown、Finger Wagなどの「処分」は、恒久番号、DOI、公式アーカイブ、BCP 14の大文字語をまとった風刺である。文書の真正性は保証されても、IETFの執行行為にはならない。
  • 調達、監査、遮断、処罰に引用を使う側は、識別子、stream、status、日付、標準上の位置、IANA効果、系譜、ジャンル根拠を結ぶ記録を添えるべきだ。目的は笑いを消すことではなく、引用が権力へ変わる接点を可視化することにある。

番号は正しくても判定は誤り得る

RFC 9948は偽文書ではない。RFC Editorの公式サイトにあり、番号とDOIを持ち、公開後に本文が書き換わらないRFC Seriesの一部である。「公式か」と問われれば、アーカイブ上の答えは明確に「はい」だ。

だが、「公式」という一語は、その文書が誰に何を命じられるかを答えない。

情報ページでは、公開日は2026年4月1日、streamはIndependent、statusはInformationalとなっている。本文冒頭の定型文は、Internet Standards Track仕様ではないと述べる。RFC Editorは実装または配備の価値について見解を示さず、このstreamで承認された文書はInternet Standardのどの段階にも進まない。

したがって番号は文書同一性の証明であり、執行権の証明ではない。streamは公開に至る制度経路を示し、statusは成果の種類を示す。現在の製品や契約に現実の効果を与えるには、実装者の適合宣言、買い手の契約条項、組織の内部決定、法令による取り込みなど、別の主体による別の行為が要る。

その行為を記録せずに「RFCが要求する」と書けば、決めた人物だけが見えなくなる。

真顔を保てることが作品の条件だった

RFC 9948の処分表は段階的である。小さな文法上の罪にはRaised Eyebrow。より深刻ならFrown。隠された複雑性にはShaking of the Head。別の4月文書に関係する問題にはFinger Wag。HTMLとHTTPの全含意を理解した古参が行ったというHead-in-Hand Gestureは、ほとんど神話である。

プロトコル開発中に聞こえる「ここは詳しく書く必要がある」「何かを考慮し忘れているかもしれない」「脅威モデルが未成熟だ」といった言葉も登場する。ただしRFC自身が、これらの発言はそれだけでは処分にならないと書く。濡れた麺を用いる説得も採用されない。

この作品はRFC 8962の続編である。2021年4月1日に公開された前作はProtocol Policeを「設立」した。そちらもIndependent Stream、Informationalであり、Standards Trackでも配備勧告でもない。

RFC 8700が記録したRFC Seriesの歴史によれば、4月1日RFCはIndependent Streamの特別な一部で、ユーモアを目的とした文書だった。しかも、読者がしばらく本気の文書だと思えることが選考上の美点とされた。形式的な類似はバグではない。風刺の実装である。

だから、機械が誤る可能性を理由に作品を非公式化してはいけない。必要なのは真顔を壊すことではなく、現実の決定まで真顔が持ち越されない仕組みだ。

大文字語はstreamを越えて昇進しない

RFC 9948は、すべて大文字で現れるMUST、SHOULD、MAYなどをBCP 14に従って解釈すると述べる。架空の処分に仕様書の語法を与えるため、重要な仕掛けになっている。

しかし要求語は、すでに定まった文書範囲の内部で強度を表す。どのstreamが公開したか、どのstatusか、誰が採用したか、誰が制裁できるかは決めない。MUSTの字体だけでIndependent Informational文書がProposed Standardになることはない。

RFC 3935は、IETF standardでさえ一般的な使用命令ではないと説明する。標準に従っていると主張する者に対し、そのように行うなら記述どおりに行うことを求めるのであって、IETFが採用を強制したり使用を取り締まったりする意味ではない。RFC 9592にも「IETFはprotocol policeではない」という言い回しが残る。

引用されたMUSTには、少なくとも三つの欄が必要だ。どの文書の語か。その文書のstreamとstatusは何か。現在の相手に効果を及ぼす採用行為を誰が行ったか。最後の欄が空なら、命令形はあるが管轄はない。

断片化は事実を捏造せずに意味を変える

この調査は、RFC 9948を実在の規則として扱った検索サービス、AI、企業、行政機関を確認していない。起きていない事故を作るべきではない。

確認できるのは、文書の流通形態である。検索スニペット、ベクトル検索の一節、知識グラフのノード、生成要約、適合表のセルでは、番号と短い命令が残りやすい。streamやstatusを説明する数文は「共通定型」として削られやすい。文字列は正確でも、権限関係は逆転し得る。

4月1日だけを判定器にする方法も危険だ。RFC Seriesの歴史は、その日付の文書がすべて風刺とは限らないことを示してきた。逆に文体だけを見れば、真面目に見えるよう作られた良い風刺ほど誤る。

RFC 9948の場合、ジャンル根拠は複合的だ。日付、Independent Stream、Informational、非標準・非配備の定型文、RFC 8962との系譜、架空組織、現実にあり得ない処分、IANA actionがないこと、RFC 8700の歴史記述が同じ方向を指す。高い影響を持つ分類は、この束を保存すべきである。

ジャンルと権限の記録

提案する記録は、RFC本文を編集するものでも、公開APIの修正要求でもない。引用を使って結果を出す側が作り、公式情報から検証できる小さな随伴物である。

識別欄にはRFC番号、正式タイトル、DOI、本文ハッシュ、公開日、参照した情報ページの時点を置く。制度欄にはstream、status、stream approver、errata、更新・廃止関係を置く。

権限欄では、Standards TrackまたはBCPへの所属、合意や配備価値を説明するboilerplate、IANA action、現在の採用文書を分ける。調達なら契約条項と責任者、製品適合ならバージョンと試験、組織ポリシーなら承認記録を示す。RFC 9948のIANA actionはゼロである。

ジャンル欄には一つではなく複数の根拠、関連文書、引用前後の文脈、翻訳上の扱いを置く。反語や文化参照が結論を左右する場合は、人間による確認をトリガーにする。

最後に、作成者、確認日、証明できない事項、更正の伝播先を記録する。元データを直しても、それから作られた拒否ルールが残れば修正は終わっていない。

この記録自体がジャンル警察になってはならない。掲載の許可を出すのではなく、引用から結果までの責任を表示する。

IETFへのリンクは帰属を意味しない

RFC 9948はIETF文化を題材にし、本文でもIETFの言葉を使う。本記事がIETFのdirectory contextを示すのはそのためであり、RFCをIETF Streamへ移すためではない。

RFC Editorの現行ガイドは、Independent StreamがIETF、IAB、IRTFの公式プロセス外で公開されると説明する。RFC 8729はstreamごとの承認過程を分ける。RFC 7841のヘッダーとboilerplateも、同じRFC Series内で異なる制度出所を読者に伝えるためにある。

正確な関係は四層になる。RFC Seriesの真正な文書。Independent Streamの出版物。Informationalというstatus。IETF文化を扱うが、IETF Standards Trackの権限を持たない作品。一つの「組織」欄だけでは、この関係を表せない。

眉を上げる自由と、罰しない義務

技術レビューの厳しい指摘には価値がある。実装が相互運用しないなら、運用者は受け入れない選択をできる。ワーキンググループは文書を修正できる。買い手は要件を契約に書ける。それぞれが自分の行為を自分の名で記録すればよい。

RFC番号に判断主体を代行させる必要はない。むしろ代行させれば、技術的根拠も異議申立先も薄くなる。

RFC 9948は正式な歴史として残すべきだ。Raised Eyebrowも風刺として残すべきだ。執行権だけは、最初からそこにない。

情報源

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. RFC Editor — RFC 9948情報ページ
  5. RFC 9948 — Internet Protocol Police (IPP): Schedule of Punishments
  6. RFC Editor — RFC 8962情報ページ
  7. RFC 8962 — Establishing the Protocol Police
  8. RFC 8700 — Fifty Years of RFCs
  9. RFC Editor — What Is an RFC?
  10. RFC 8729 — The RFC Series and RFC Editor
  11. RFC 7841 — RFC Streams, Headers, and Boilerplates
  12. RFC 3935 — A Mission Statement for the IETF
  13. RFC 9592 — Retiring the Tao of the IETF