信頼度
1- 公的役割
- ただし、RIR または RIPE が情報源として参照されていても、その機関の管轄や商用ネットワークサービスとして扱われるものではありません。
- 情報の種類
- BTW は、IETF を標準・ガバナンスのエコシステムの一部として追跡し、機関のアイデンティティ、公開情報源の証跡、未解決の関連性の手がかりをそれぞれ分けて管理しています。
関連情報
最終更新日: 2026-07-03
現在の状態
サービス
1関連調査
27- RFC 9919のSHA-1件数は廃止の証拠にならない
OCSPレスポンダーのグラフからSHA-1が消えても、互換性を必要とする利用者まで消えたとは限らない。RFC 9919のログ提案を、観測範囲と決定責任を備えた廃止記録へ変える必要がある。
主要記事公開日 2026-09-15 - アルゴリズム表示は変わった。鍵は追随しない――RFC 9709が定める証拠の境界
暗号を破らなくても、暗号文の「読み方」を示す識別子を書き換えれば、復号側を推測装置に変えられる場合がある。RFC 9709は、識別子の完全な符号化を鍵導出に組み込み、処理成功と信頼判断を切り離す。
主要記事公開日 2026-09-15 - JPEG と書かれ、OID は GIF を示した:RFC 2158 の形式同一性
短い仕様書の一行が、周囲のすべてと食い違っている。RFC 2158 の節見出しは GIF、X.400 本文部名も GIF、OID の末尾も `gif-image(4)` なのに、MIME Content-Type だけが `image/jpeg` だった。この矛盾は、公開されたラベルと実際の形式、意図、実装結果を同じ事実として扱えないことを示す。
主要記事公開日 2026-09-15 - RFC 2070 が切り分けたもの:同じ文字へ至る異なるバイト列
HTML の数字文字参照は、ASCII 互換のファイルでも多バイトの UCS 表現でも、正しく復号された後には同じ文字を指さなければならない。RFC 2070 は、この性質を「Unicode 対応」という曖昧な看板ではなく、境界の設計として示した。`charset` は外部オクテットを文書文字へ移すデコーダーを選び、HTML の抽象的な UCS 文書文字集合は固定される。フォントや画面表示は、その後段に残った別の問題だった。
主要記事公開日 2026-09-15 - 証拠を見る前に都市を落とす「選好」――RFC 9712 が引き直した会場決定の境界
現地調査を受ける前に候補から消える都市がある。試験に落ちたのではない。「同じ屋根の下が望ましい」という選好が、いつの間にか合否基準として働いたからだ。RFC 9712 は短い会場方針の改訂だが、示す統治上の教訓は大きい。決定者、測定可能な境界、エスカレーション、費用移転を分けて記録して初めて、裁量は検証できる。
主要記事公開日 2026-09-15 - 片道の変換は同値ではない:RFC 2157 が求めた帰路の証拠
添付ファイルがゲートウェイを通り、バイト列が残り、もっともらしい名前まで付いて戻ってきても、それだけで同値とは言えない。RFC 2157 は、片方向の変換を mapping と呼び、二つの mapping を組み合わせて損失なく元へ戻せる場合だけを equivalence とした。encapsulation はさらに別の約束であり、中継側が内容を理解できなくても原形式への帰路を保存するものだった。
主要記事公開日 2026-09-15 - 時刻入りnonceは二度目を知らない――RFC 2069が残した再送判定の境界
ある認証要求が午後3時00分に受理され、同じ16進文字列が3時01分にも届いたとする。nonceの有効期限が5分なら、二つとも正しく計算され、期限内に見える。それでも二度目を拒否できるかは、ハッシュ式ではなくサーバーの記憶にかかっていた。RFC 2069は、鮮度の上限と一回性が別の性質であることを、運用コストまで含めて記していた。
主要記事公開日 2026-09-15 - 実装できることと、稼働中の適合は別だった:RFC 2156
MIXER の全機能を備えた製品でも、実際にメールを中継するゲートウェイが狭いローカル設定のままなら、世界規模の適合性は証明されない。RFC 2156 は配布リストが運用範囲を静かに広げることを見抜き、適合性を製品ではなくインスタンスに結び付けた。
主要記事公開日 2026-09-15 - EVPNはマルチキャスト送信元を選べても冗長性を証明できない
受信機の重複カウンターがゼロでも、冗長化が実証されたとは限らない。RFC 9856は、EVPNで余分なマルチキャストコピーをどこで抑止するかを定める。しかし、送信元の同等性、健全性、無損失の切替え、すべての受信者の連続性までは証明しない。選択の記録とサービスの証拠を分けて残す必要がある。
主要記事公開日 2026-09-15 - レジストリは版を示した。意味までは与えない――RFC 9713
RFC 9713 が IANA の表に加えたのは、わずか一列だった。しかし、その列は運用上の重要な誤解を可視化した。番号が割り当て済みで BPv7 に適用でき、公開割当との衝突も避けられていても、受信側が内容を理解すること、送信側の私的な規約に合意すること、あるいは処理を実行する権限を持つことまでは証明されない。
主要記事公開日 2026-09-15 - HTTP/1.1は今回の機能一覧ではなかった――RFC 2068が次の通信に残した約束
メッセージの先頭行にある`HTTP/1.1`は、いま目の前にある処理の完了票ではない。1997年のRFC 2068がその数字に持たせた役割は、送信者が採用したメッセージ形式と、今後のHTTP通信で理解できる能力の上限を知らせることだった。途中にプロキシが入れば、その約束をする主体も次のホップごとに入れ替わった。
主要記事公開日 2026-09-15 - 読めるアドレスは、回線上の識別子ではなかった:RFC 2155
RFC 2155 は、APPN の管理画面に読みやすいデータリンク・アドレスを用意しながら、それを表示専用と定めた。DLC ヘッダーを実際に流れるバイト、稼働状態、相手から得た識別情報、セッション成立は、それぞれ別の証拠だった。
主要記事公開日 2026-09-15 - 破棄の通知を受けても、予約を残す理由
RFC 9705のConditional PathTearは、一律に状態を消す命令ではない。受信側がどの保護役割を担い、隣接ルーターが何を実装すると合意したかによって、正しい処理が変わる。
主要記事公開日 2026-09-15 - 応答は三つのドメインを越えた。証拠の権限は越えていない
RFC 9716 は、通常の IP 戻り到達性がない SR-MPLS の複数ドメインでも、LSP ping と traceroute の応答を返せるようにする。戻りラベルスタックは送信元が完成させても、境界ルータが段階的に組み立ててもよい。だからこそ、受信した Echo Reply は一回の診断交換の証拠であり、本番サービス全体の健全性証明ではない。
主要記事公開日 2026-09-15 - RFC 2067:使われなかった三つのパケット形式を削って標準は前進した
IP over HIPPI の成熟は、機能追加ではなく選択肢の整理として現れた。RFC 2067 は RFC 1374 が許していた三つの形式を、稼働中の実装が使っていないという記録に基づいて禁止した。同時に相互運用性の主張を、単一の HIPPI-SC スイッチまたは単純な双方向直結に限定した。実装経験が削除を支え、トポロジーが証明の外縁を決めた。
主要記事公開日 2026-09-15 - DTLSの到達往復確認は移行記録ではない
正しいConnection IDを持つ保護済みデータグラムが、これまでと違う送信元アドレスから届く。暗号処理は既存のDTLSセキュリティコンテキストを見つけられる。しかし、そのコンテキストを新しい経路へ移し、アプリケーションデータを送り、結果を監視し、必要なら戻すという判断は別に残る。RFC 9853が与えるのは限定された経路確認であり、その判断全体ではない。
主要記事公開日 2026-09-15 - 署名は発信者を示した。それでもリンクの実在は証明できない――RFC 2154
RFC 2154 は、OSPF の LSA に洪水伝播の途中でも失われない発信元証拠を持たせた。中継ルータによる書き換えは検出できる。だが発信ルータ自身が、誤ったメトリックや存在しない stub 経路を正しく署名する余地は残った。
主要記事公開日 2026-09-15 - TreeDNで複製が減っても、視聴の完了は証明できない
ライブ映像を運ぶコピーを減らすことと、見たい人に間に合う映像を届けることは同じではない。RFC 9706が切り分ける複製サービスには、証拠の境界も必要になる。
主要記事公開日 2026-09-15 - 軌道はリンクの準備完了を示した。ネットワークはまだ同意していない
RFC 9717 は、予測と観測を混同せずに軌道の予測可能性をルーティングへ生かす。予定トポロジーは事前準備を可能にするが、スケジュール、計算済み SID リスト、インストール成功の応答は、稼働中の光リンクや顧客トラフィックの到達とは別の事実である。
主要記事公開日 2026-09-15 - RFC 2066:文字集合はすでに正しかった。それでも返答は必要だった
Telnetには、確認の往復を止める古い規律があった。すでに有効なモードを求められたなら返答しない。RFC 2066は文字集合のサブネゴシエーションについて、あえて例外を設けた。受信側が提示された文字集合をすでに使っていても`ACCEPTED`を返さなければならない。沈黙では要求側がタイムアウトから結果を推測するしかないからだ。双方が同時に要求した場合は、サーバーが拒否し、クライアントが応答する。明示的な受領証と非対称な衝突規則が、符号化の変更を終端可能な状態機械にした。
主要記事公開日 2026-09-15 - 名前空間は衝突を防いだ。理解までは運ばない:RFC 2153
RFC 2153 は、独自 PPP 拡張に Code または Type 0、OUI、Kind、独自 Values という共通の外枠を与えた。番号の衝突は避けられる。しかし、受信側が意味を理解し、利用を許可し、相互運用できたことまでは示さない。
主要記事公開日 2026-09-15 - RFC 2065:普通のDNSサーバーは答えを運べた。信頼を決めたのは署名だった
1997年1月のRFC 2065は、DNS応答を中継するすべての機械に判定権を与えずに、認証を導入する道を示した。セキュリティー対応リゾルバーは、拡張を理解しないサーバー経由でも署名付きレコードを受け取り、自ら証拠を検査できた。守る対象は公開DNSデータの出所と完全性であり、問い合わせの秘密や利用資格ではなかった。
主要記事公開日 2026-09-15 - 読める部分は残った。それでも原文保存の証明にはならない――RFC 2152
UTF-7は、7ビットのメール経路にUnicodeを通しながら、ASCII部分をそのまま読める形に残した。ただし、その見通しのよさは保全証明ではない。句読点には複数の合法な表現があり、シフト列は改行を越えられず、同じ文字列を復号できても元のバイト列までは復元できない。
主要記事公開日 2026-09-15 - サーバーは話すのをやめ、クライアントはまだ聞き取った――RFC 2062
1996年12月、IMAPは移行に方向があることを明文化した。古い構文を新たに生成しないことと、旧実装から届く構文を読めることは別の義務である。RFC 2062は、過去を送り出す権限を止めながら、設置済みの相手を退場させるための受信互換性を限定的に残した。
主要記事公開日 2026-09-15 - 応答は観測であって権威ではない――RFC 2151が示した診断の境界
RFC 2151は1997年、名前、往復応答、中継点、遠隔サービスを一般利用者の端末から見えるものにした。しかし、画面に現れた一行は特定条件でのやり取りの記録であり、経路全体や相手の身元、サービス成果を認定する権限ではなかった。
主要記事公開日 2026-09-15 - TLSのCertificateRequestコンテキストは応答を対応付けるが、認可範囲ではない
サーバーは証明書要求に不透明な値を付け、後からどの応答がその要求に対応するかを識別できる。これは暗号上の会話を整理する仕組みであって、請求情報の閲覧権や管理操作の実行権を与えるものではない。対応付けの印だけを保存し、その意味を与えた認可判断を捨てるとき、実装上の便利さがガバナンス上の欠落に変わる。
主要記事公開日 2026-09-15 - RFC 2150――「同じ舞台に立つ」という招待が残した、文化とネットワークの条件
文化資料のファイルはすでにサーバーにあり、検索結果にも名前が出る。それでも、実際に復元できるか試した者はいない。形式が古くなったとき誰が更新するのか、誰が記述し、誰が利用条件を説明し、教育の場でどう扱い、必要な資源を誰が負担し、最終的な判断を誰が下すのかも曖昧である。RFC 2150 を四半世紀以上前の入門書としてだけ読むと、この問題の核心を見落とす。1997年の文書が記録したのは、文化をネットワークへ載せる可能性だけでなく、「そこに存在する」ために必要だった技術、記述、保存、資源、権利、参加の条件の厚みだった。
主要記事公開日 2026-09-15
