要約

  • RFC 5242 は正規のRFC Series出版物だが、自身のメタデータとIESG Noteが、情報提供目的のユーモアであり、IETF文書でも標準候補でもなく、未完成だと明示する。
  • 番号は「どの文書か」を答える。状態、出版元、機関注記、版、実装、運用採用は別の問いであり、番号から推定してはならない。

限定語を失った引用

設計書に「文字処理はRFC 5242に従う」と書かれていたとする。番号もリンクも正しい。しかし本文が提案するのは、見た目が同じなら同じ文字として扱い、文字を線や結合要素から組み立て、3と23が素数で42はそうでないという理由を交えて23ビットを選ぶ体系である。連絡先は意図的な偽ドメインで、日付は4月1日だ。

笑いを読み取る能力に判断を委ねる必要はない。RFC Editorの情報ページには humor とある。分類はInformational。IESG Noteは、IETF文書ではなく、Internet Standardのどの段階にも進まないこと、安全性や既存プロトコルとの相互作用についてIETF審査を受けておらず、実装・配備の価値を慎重に評価すべきだと記す。要約も仕様が完全ではないと認める。

番号と表題だけを残す知識ベースは、権威らしく見える部分を保存し、権威を制限する部分を捨てる。

番号には本物の役割がある

だからといってRFC番号を軽視すべきではない。番号は安定した識別子、正規の保存場所、長期に使える参照を与える。RFC 5242が示すのは、強い文書同一性と、明確に存在しない標準権威が両立することだ。

RFC Seriesには複数のストリームとカテゴリーがある。RFC 4844、5741、7841、8729は、由来と状態を読者へ伝える仕組みを説明する。Standards Track、Best Current Practice、Experimental、Informationalは同義ではない。

番号は「どれか」。状態と出版経路は「どの手続きで、何を主張する出版か」。IESG Noteは解釈をさらに限定する。UpdatesとObsoletesは後続関係を示す。それらすべてが揃っても、動く実装や配備を直接証明しない。

出版と採用の間にある段階

RFC Editorが出版したことは編集上の事実であり、IETF合意ではない。標準化された文書でも、相互運用実装が存在するとは限らない。コードがあっても広い配備とは限らず、配備は安全性や効果の証明ではない。

RFC 5242について、この証拠集合は製品、運用導入、障害、測定結果を示さない。UnicodeやIDNAの現実的な代替として語れば、資料にない事実を追加することになる。

意思決定用のデータモデルは、番号、表題、日付、カテゴリー、出版経路、明示注記、更新・廃止関係を同じ画面に載せるべきだ。高リスクな採用では審査経路、完全性、適合試験、配備観測も必要になる。

検索画面が権威を洗う

検索結果は番号と表題を先に出し、警告を後ろへ追いやる。要約生成は技術部分を抽出し、IESG Noteを落としやすい。局所的には正確でも、全体としてユーモアを要求事項へ変換できる。

修正は、引用の横に限定を置くことだ。「RFC 5242、Informationalのユーモア、非IETF文書」と「RFC 5242」だけでは、読者が受け取る主張が違う。

IESGは国際化ドメイン名の言語・運用・安全上の課題を扱うRFC 4690を参照する。RFC 3490のIDNA2003は、RFC 5890と5891を含むIDNA2008群に置き換えられた。Unicodeにも独立した版管理がある。RFC 5242は同じ領域を題材にするが、その審査権威を継承しない。

技術権威を扱うなら、文書同一性、状態と出版元、機関注記、版と後継、実装、配備と結果の六つを別々に保存する。Lu Hengが重視する検証可能な現実に従えば、評判のあるラベルを、帰属可能な手続きや観測結果より先へ走らせてはならない。

情報源