エイプリルフールのコメント募集

インターネット ガバナンスの文脈における Request for Comments (RFC) は、インターネット技術タスク フォース(IETF) およびインターネット協会(ISOC)からの出版物の一種であり、通常はインターネットおよびインターネットに接続されたシステムの動作に適用可能な方法、動作、研究、または革新について説明します。

1989年以来、ほぼ毎年エイプリルフール（4月1日）に、インターネットRFCエディターは、1973年6月のRFCに倣って、 1つ以上のユーモラスなRequest for Comments（RFC）文書を公開してきました。 527 はARPAWOCKY と呼ばれ、ルイス・キャロルのナンセンス詩「ジャバウォック」のパロディです。次のリストには、他の日付で公開されたユーモラスなRFC も含まれています。

• M. Crispin (1978 年 4 月1日)。TELNET RANDOMLY-LOSE オプション。IETF。doi : 10.17487 / RFC0748。RFC 748。 未知。

TCP/IPドキュメント スタイルのパロディです。長い間、RFC インデックスでは「発行日を注記」という特別なマークが付けられていました。

• B. Miller (1989 年 4月1 日)。TELNET サブリミナル メッセージ オプション。ネットワーク ワーキング グループ。doi : 10.17487/ RFC1097。RFC 1097 。 未知。

• D. Waitzman (1990 年4月 1 日)。鳥類キャリアにおける IP データグラムの伝送に関する標準。ネットワーク ワーキング グループ。doi : 10.17487/ RFC1149。RFC 1149 。 実験的。

1999 年に RFC 2549 によって更新されました。下記を参照してください。伝書鳩によって IP パケットを送信するためのプロトコルについて説明します。

2001年に、RFC 1149はBergen Linux User Groupのメンバーによって実際に実装されました^[1]。

下記の RFC 6214 も参照してください。RFC 1149 のIPv6への適応について説明しています。

• Poorer Richard、Kynikos 教授 (1991 年4月 1 日)。ギガビット ネットワークの経済性とパラダイム シフト。ネットワーク ワーキング グループ。doi : 10.17487/ RFC1216。RFC 1216 。 情報提供。
• V. Cerf (1991 年 4 月 1 日)。スローコモーション研究コンソーシアム (CSCR) からのメモ。ネットワークワーキンググループ。doi : 10.17487 / RFC1217。RFC 1217 。 情報提供。

• C. Partridge (1992 年4月 1 日)。KRFC AM 1313 インターネット トーク ラジオの今日の番組。ネットワーク ワーキング グループ。doi : 10.17487 /RFC1313。RFC 1313。 情報提供。

• N. Borenstein、M. Linimon (1993 年 4 月 1 日)。MIME コンテンツ タイプの新しいメディアへの拡張。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1437。RFC 1437 。 情報提供。
• L. Chapin、C. Huitema (1993 年 4 月 1 日)。インターネット エンジニアリング タスク フォースの退屈に関する声明 (SOB)。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1438。RFC 1438 。 情報提供。

• W. シェイクスピア(1994 年 4 月 1 日)。SONET から Sonnet への変換。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1605。RFC 1605 。 情報提供。

ウィリアム・シェイクスピア作とされる。

• J. Onions (1994 年 4 月 1 日)。IP バージョン 9 の使用に関する歴史的観点。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1606。RFC 1606 。 情報提供。
• V. Cerf (1994 年 4 月 1 日)。21 世紀からの視点。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1607。RFC 1607 。 情報提供。

• S. Crocker (1995 年 4月1 日)。アドレスはメッセージです。ネットワーク ワーキング グループ。doi : 10.17487/ RFC1776。RFC 1776 。 情報提供。

• R. Elz (1996 年 4 月 1 日)。 IPv6 アドレスの簡潔な表現。ネットワーク ワーキング グループ。doi : 10.17487/RFC1924。RFC 1924。 情報提供。
• R. Callon 編 (1996 年 4 月 1 日)。ネットワークに関する 12 の真実。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1925。RFC 1925 。 情報提供。
• J. Eriksson (1996 年 4 月 1 日)。「ATM 上での IP データグラムの実験的カプセル化」。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1926。RFC 1926 。 情報提供。
• C. Rogers (1996 年 4 月 1 日)。「ドキュメントを関連付けるための追加の MIME タイプの提案」。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1927。RFC 1927 。 情報提供。

• J. Ashworth (1997 年 4 月 1 日)。ホストの命名。ネットワーク ワーキング グループ。doi : 10.17487 / RFC2100。RFC 2100 。 情報提供。

• A. Bressen (1998 年4月 1 日)。RITA - 信頼性の高いインターネットワーク トラブルシューティング エージェント。ネットワーク ワーキング グループ。doi : 10.17487/ RFC2321。RFC 2321 。 情報提供。
• K. van den Hout、A. Koopal、R. van Mook (1998 年 4 月 1 日)。peg-dhcp による IP 番号の管理。ネットワーク ワーキング グループ。doi : 10.17487/ RFC2322。RFC 2322 。 情報提供。

この RFC は娯楽のためだけのものではありません。説明されているプロトコルは、ヨーロッパのハッカー イベントで定期的に実装されてきました。

• A. Ramos (1998 年4月 1 日)。IETF 識別およびセキュリティ ガイドライン。ネットワーク ワーキング グループ。doi : 10.17487/ RFC2323。RFC 2323 。 情報提供。
• L. Masinter (1998 年 4 月 1 日). ハイパーテキスト コーヒー ポット制御プロトコル (HTCPCP/1.0). ネットワーク ワーキング グループ. doi : 10.17487/RFC2324 . RFC 2324. 情報提供。2014年に RFC 7168 によって更新されました。

• M. Slavitch (1998 年 4 月 1 日)。SMIv2 を使用したドリップ式加熱飲料ハードウェア デバイスの管理オブジェクトの定義。ネットワーク ワーキング グループ。doi : 10.17487 / RFC2325。RFC 2325 。 情報提供。

• D. Waitzman (1999 年 4 月 1 日)。IP over Avian Carriers with Quality of Service。ネットワーク ワーキング グループ。doi : 10.17487 /RFC2549。RFC 2549 。 情報。RFC 1149 を更新します。

• S. Glassman、M. Manasse、J. Mogul (1999 年 4 月 1 日)。Y10K 以降。ネットワーク ワーキング グループ。doi : 10.17487 / RFC2550。RFC 2550 。 情報提供。
• S. Bradner (1999 年 4 月 1 日)。ローマ標準プロセス - 改訂 III (MCMXCIV 4 月 1 日)。ネットワーク ワーキング グループ。doi : 10.17487 / RFC2551。RFC 2551 。 現在の最悪のプラクティス。MCMXCIX は廃止されます。

• S. Christey (2000 年 4 月 1 日). The Infinite Monkey Protocol Suite (IMPS). Network Working Group. doi : 10.17487/RFC2795 . RFC 2795. 情報提供。

無限猿定理の実用性について。

• H. Kennedy (2001 年 4 月 1 日)。Pi 桁生成プロトコル。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3091。RFC 3091 。 情報提供。
• D. Eastlake III、C. Manros、E. Raymond (2001 年 4 月 1 日)。「Foo」の語源。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3092。RFC 3092 。 情報提供。
• M. Gaynor、S. Bradner (2001 年 4 月 1 日)。ファイアウォール拡張プロトコル (FEP)。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3093。RFC 3093 。 情報提供。

• B. Rajagopalan (2002 年 4 月 1 日)。IP 経由の電力。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3251。RFC 3251 。 情報提供。

「Everything over IPとIP over Everything」^[2]と2000～2001年のカリフォルニア電力危機のパロディ。

• H. Kennedy (2002 年 4 月 1 日)。バイナリ レキシカル オクテット アドホック トランスポート。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3252。RFC 3252 。 情報提供。

• S. Bellovin (2003 年 4 月 1 日)。IPv4 ヘッダーのセキュリティ フラグ。ネットワーク ワーキング グループ。doi : 10.17487/ RFC3514。RFC 3514 。 情報提供。

IPv4 パケット ヘッダーのオプションとして「悪意のあるビット」を提案。後に、これは悪意のある行為者の自発的な参加を必要とする困難な人間社会問題に対する単純な技術的解決策を求めるすべての試みの同義語になりました。

• S. Bradner (2004 年 4 月 1 日)。Omniscience Protocol の要件。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3751。RFC 3751 。 情報提供。

• A. Farrel (2005 年 4 月 1 日)。ルーティングエリアドラフトのモラリティセクションの要件。ネットワークワーキンググループ。doi : 10.17487 / RFC4041。RFC 4041 。 情報提供。
• M. Crispin (2005 年 4 月 1 日)。Unicode の UTF-9 および UTF-18 の効率的な変換形式。ネットワークワーキング グループ。doi : 10.17487/ RFC4042。RFC 4042 。 情報提供。

メーカーが PDP-10 の生産を中止してから約 22 年経ってもPDP-10アセンブリ言語コードが収録されており、他の多くの提案とは対照的に技術的に可能であることで注目に値します。

• M. Schulze、W. Lohsen (2005 年 4 月 1 日)。IP over Burrito Carriers。IETF。ID draft-lohsen-ip-burrito-00。

今年は 4 月 1 日の RFC は発行されませんでしたが、セサミストリートのキャラクターBert をIAB のメンバーに任命するという IETF リストでの発表は、2006 年のエイプリル フールのいたずらだったようです。

• J. Hofmueller、A. Bachmann、IO. zmoelnig 編 (2007 年 4 月 1 日)。セマフォ フラグ シグナリング システム (SFSS) による IP データグラムの転送。ネットワーク ワーキング グループ。doi : 10.17487 / RFC4824。RFC 4824 。 情報提供。

• A. Falk、S. Bradner (2008 年 4 月 1 日)。IETF プロトコルの命名権。ネットワーク ワーキング グループ。doi : 10.17487 / RFC5241。RFC 5241 。 情報提供。
• J. Klensin、H. Alvestrand (2008 年 4月1 日)。一般化統一文字コード: 西ヨーロッパおよび CJK セクション。ネットワーク ワーキング グループ。doi : 10.17487/ RFC5242。RFC 5242 。 情報提供。

• A. Farrel (2009 年 4 月 1 日)。3 文字の頭字語に関する IANA の考慮事項。ネットワーク ワーキング グループ。doi : 10.17487 / RFC5513。RFC 5513 。 情報提供。
• E. Vyncke (2009 年 4 月 1 日)。ソーシャル ネットワーク上の IPv6。ネットワーク ワーキング グループ。doi : 10.17487 / RFC5514。RFC 5514 。 実験的。

RFCの執筆中に著者がFacebookに実装しました。 ^[3]

• R. Hay、W. Turkal (2010 年 4 月 1 日) 。パケットのムードを示す TCP オプション。独立投稿。doi : 10.17487 / RFC5841。ISSN 2070-1721。RFC 5841  。 情報提供。

• B. Carpenter 、R. Hinden (2011 年4月 1 日) 。RFC 1149 の IPv6 への適応。インターネット エンジニアリング タスク フォース。doi : 10.17487/ RFC6214。ISSN 2070-1721。RFC 6214  。 情報提供。

• T. Ritter (2011 年4月 1 日)。大気圏リンク層を使用した地域ブロードキャスト。独立投稿。doi : 10.17487/ RFC6217。ISSN 2070-1721。RFC 6217  。 実験的。

• C. Pignataro (2012 年 4 月 1 日) 。Nullパケット。独立投稿。doi : 10.17487/ RFC6592。ISSN 2070-1721。RFC 6592  。 情報提供。
• C. Pignataro、J. Clarke、G. Salgueiro (2012 年 4 月 1 日)。ドメイン仮名システム (DPS) の Hide-and-Go-Seekを使用したサービス未検出。独立投稿。doi : 10.17487 / RFC6593。ISSN 2070-1721。RFC 6593  。 情報提供。

• R. Barnes、 S . Kent、E. Rescorla (2013 年 4 月 1 日)。要件レベルを示すために RFC で使用するその他のキーワード。独立投稿。doi : 10.17487 / RFC6919。ISSN 2070-1721。RFC 6919  。 実験的。
• R. Hinden (2013 年 4 月 1 日) 。超光速 (FTL) 通信の設計上の考慮事項。独立投稿。doi : 10.17487 / RFC6921。ISSN 2070-1721。RFC  6921 。 情報提供。

インターネット上で光速よりも速くパケットを送信できるようになると、パケットは送信前に受信される可能性があり (時間の逆転のため)、これは現在使用されている多くのプロトコルに大きな影響を与えます。十分な速度 (および対応する負の時間シフト) があれば、通信が開始される前に通信が完了している可能性があります。RFC は、将来の通信の中断を防ぐために、これらのプロトコルの設計原則を見直します。おそらく、昨日からアップグレードを開始しておくべきでした。

• I. Nazar (2014 年 4 月 1 日)。紅茶流出機器用ハイパーテキスト コーヒー ポット制御プロトコル (HTCPCP-TEA)。独立投稿。doi : 10.17487 / RFC7168。ISSN 2070-1721。RFC 7168  。 情報提供。

RFC  2324を更新して、お茶を淹れることもできるコーヒー マシンに対応しました。また、コーヒーを淹れないときに使用するティーポット用のHTTP 応答コード418 I'm a Teapotも定義しています。

• S. Turner (2014 年4月 1 日)。NSA (No Secrecy Afforded) 証明書拡張。独立提出。doi : 10.17487 / RFC7169。ISSN 2070-1721。RFC 7169  。 情報提供。

一般的には望ましくないが、X509デジタル証明書の秘密鍵の対応物は、合法的な傍受やその他の理由で第三者と共有されているか、共有されていた可能性があります。ブール値を指定する新しい証明書拡張機能により、ユーザーはこの事実を通知されるようになりました。「true」の場合、秘密鍵は共有されています。「false」の場合、署名者は共有が行われたかどうかについてコメントを控えます。 ext-KeyUsage

• M. Wilhelm (2015 年 4 月 1 日)。IPv6 向け風景ルーティング。独立投稿。doi : 10.17487 / RFC7511。ISSN  2070-1721。RFC 7511。 実験的。

グリーン IT の重要性はますます高まっています。パケットと環境の両方にとってメリットのある提案として、この RFC では、パケットを空中にルーティングして、できるだけ多くの日光と新鮮な空気を得られる方法を定義します。パケットをWi-Fiまたは鳩で送信することで、パケットは組み立てと分解の苦痛なルーチンから解放され、ダークファイバーや銅線を常に通過する必要がなくなります。

• M. Luckie (2015 年4月 1 日)。Really Explicit Congestion Notification (RECN)。独立投稿。doi : 10.17487 / RFC7514。ISSN 2070-1721。RFC 7514  。 実験的。 競合する他のフローに対して不公平な速度でトラフィックを継続的に生成し、以前のパケット損失や ECN マークに反応していないホストへの応答として、ルータは RECN メッセージを送信する必要があります。

現在では廃止されているICMP Source Quenchに似たアプローチで、パケットの「タイプ」フィールド (4) を再利用して、送信者に (実際にはECNよりも明示的に) 黙るように伝えます。トラフィックを担当するユーザーは、音声合成、またはオーディオ チャネルがミュートされている場合はポップアップによって、RECN メッセージの内容を認識する必要があります。

4月1日のRFCは今年は発行されなかった。^[4]

• M. Danielson、M. Nilsson (2017 年 4 月 1 日)。IPv6 における複雑なアドレス指定。独立投稿。doi : 10.17487 / RFC8135。ISSN 2070-1721。RFC 8135  。 実験的。

128 ビットのIPv6 アドレス空間を従来の方法とは異なる方法で使用して、最終的に複合アドレスに到達するというかなり数学的なアプローチを採用しています。たとえば、複素アドレスの虚数部 (実数部として極座標を使用) を使用してサンタクロースに連絡できます。また、 IP over avian carriers を使用するエンド ホストにフライング アドレスを使用することも提案しています。

• B. Carpenter 、R. Hinden (2017 年4月 1 日)。IPv6 の追加移行機能。独立提出。doi : 10.17487 / RFC8136。ISSN 2070-1721。RFC 8136  。 情報提供。

インターネットアーキテクチャ委員会は、新規または拡張プロトコルのIPv4との互換性要件を緩和する予定であるため、この RFC は、すべての IPv4 パケットのevil ビットを1に設定して、デュアルスタックホストが IPv6 を優先するようにし、 Happy Eyeballsアルゴリズムも IPv6 を優先するようにすることで、 IPv6の採用を支援します。IPv4 と IPv6 の機能的同等性を維持するには、 RFC 3514の「セキュリティフラグ」をIPv6 ヘッダー に含める必要があります。高度なセキュリティオプションは、新しいホップバイホップオプションヘッダーで指定できます。

• A. Farrel (2017 年 4 月 1 日)。ASCII の芸術: あるいは、キャラクターの形で素晴らしく素晴らしいさまざまな動物の正確な表現。独立投稿。doi : 10.17487 / RFC8140。ISSN 2070-1721。RFC 8140  。 情報提供。

最も素晴らしい形のASCII アート。フルーツ コウモリ、ネス湖の怪物、バウハウスの基本的な要素、さらには鳥類の群れまでもが描かれ、注釈が付けられています。

• T. Mizrahi、J. Yallouz (2018 年 4 月 1 日)。インターネット プロトコル (IP) パケットの不正終了。独立投稿。doi : 10.17487 / RFC8367。ISSN 2070-1721。RFC 8367  。 情報提供。

^{IPレベルでのパケットの差別を終わらせようという心からの叫びです。IPレベルでのパケットの差別は、色、 [5]} 長さ、経過時間など、さらにはIPバージョンによって、頻繁に（今日でも）途中で終了されます。

• H. Kaplan (2018 年4月 1 日)。128 ビット Unicode を使用した IPv6 の国際化。独立投稿。doi : 10.17487 / RFC8369。ISSN 2070-1721。RFC 8369  。 情報提供。

現在の Unicode 実装の 1.114.112 コード ポイントは将来的には不十分であると考えられるため、IPv6の国際化を容易にするために128 ビットのUnicodeを使用することを提案します。 IPv6 アドレスは、ネットワーク管理者の目の負担を軽減するために、単一の U+128グリフで表すことができます。

実装された場合、 RFC 8135 は廃止されることになります 。なぜなら、「とにかく実装するには複雑すぎることが判明した」ためです。

• E. Fokschaner (2019 年 4 月 1 日)。ハイパーテキスト危険プロトコル ( HTJP /1.0)。独立投稿。doi : 10.17487 / RFC8565。ISSN 2070-1721。RFC 8565  。 情報提供。

HTTP/1.1に似た「応答/要求」プロトコルですが、クライアントがサーバーに応答を送信し (例: 「Hello World。ペイロードには末尾に CRLF が含まれています。」)、サーバーが Jeopardy !ゲームのように要求 (例: GET /hello.txt) で応答します。Hypertext Double Jeopardy Protocol (HTJ2P) (付録 A で説明) は、HTJP のセマンティクスを再び反転します。

• E. Rye、R. Beverly (2019 年4月 1 日)。顧客管理 DNS リソース レコード。独立提出。doi : 10.17487 / RFC8567。ISSN 2070-1721。RFC 8567  。 情報提供。

著者らは、DNS（DNSSECで保護）は、 CPE （とりわけ）のエクスペリエンスを高品質に保つために役立つ情報をグローバルかつ確実に提供するのに最も適していると主張しています。4つの新しいDNS RRタイプ（パスワード、クレジットカード番号、社会保障番号、SSNポインターレコード）の定義により、エンドツーエンドの総合的なネットワーク管理を実現したいと考えています。

• A. Mayrhofer、J. Hague (2020 年4月 1 日)。国際化された意図的に判読不可能なネットワーク表記 (I-DUNNO)。独立投稿。doi : 10.17487 / RFC8771。ISSN 2070-1721。RFC 8771  。 実験的。

テキストIP アドレスを難読化 (および置き換え) するためにUTF-8 を使用し、少数のユーザーがプレーン IP アドレスに固執 (および混同) するのではなくDNSを使用するように強制する提案。

• M. Welzl (2020 年 4 月 1 日) 。量子バグ。独立投稿。doi : 10.17487 / RFC8774。ISSN 2070-1721。RFC 8774  。 情報提供。

光より速いパケットの配送 にタイムトラベルを考慮することは「面白い」が概念としては不可能であるという考えでRFC 6921 を却下します。代わりに、パケットの往復時間に関する現実の量子もつれに焦点を当てます。パケットの往復時間は (観察者によっては) ゼロに達する可能性があります。これにより、いくつかのプロトコルに混乱が生じる可能性がありますが、問題が発生する前に「間に合うように」修正する必要があります。

• G. Grover、N. ten Oever、C . Cath、S. Sahib (2021 年 4 月 1 日)。プロトコル警察の設立。独立した投稿。doi : 10.17487 / RFC8962。ISSN 2070-1721。RFC 8962  。 情報提供。 違反の可能性がある報告や不正行為に関するヒントはすべて/dev/nullまでお送りください。プロトコル警察が対応します。

Internet Engineering Task Force は「プロトコル警察ではない」と主張しているため、ここに正式に設立されました。RFC シリーズで規定されているプロトコル定義のさまざまな側面を監視し、その遵守を強制します。彼らはウォールド ガーデンへのアクセスを許可されており、交通違反の罰則に訴えることもあります。ところで、プロトコル警察に参加することに興味がある場合は、ローカルホストに連絡してください。

• J. Snijders、C. Morrow、R. van Mook (2022 年 4 月 1 日)。有害とみなされるソフトウェアの欠陥。独立した投稿。doi : 10.17487 / RFC9225。ISSN 2070-1721。RFC 9225  。 情報提供。

ソフトウェアの欠陥を導入する習慣をなくし、コストを削減してセキュリティへの影響を少なくします。著者は、いくつかの現在のベストプラクティスを導入することで、欠陥をなくしたいと考えています。「著者はバグを実装してはなりません。コードにバグが導入された場合は、明確に文書化する必要があります。」

• M. Breen (2022年4月1日). Bioctal: Hexadecimal 2.0. 独立投稿. doi : 10.17487/RFC9226 . ISSN  2070-1721. RFC 9226. 実験的。

16 進数の数値表現に関する既知の問題は、 0 ～ 9 と AF のアルファベットを 2 つの8 進数範囲 (0 ～ 7 と文字 'cjzwfsbv' (8 ～ 15 の値をビット単位でエレガントに表現するため)) に置き換えることで回避できます。

• S. Toyosawa (2023年4月1日). TCPへのDeath ( DTH)フラグの追加。独立投稿。doi : 10.17487 / RFC9401。ISSN  2070-1721。RFC 9401。 情報提供。

ライトノベルでは慣例となっているように、「死亡フラグ」は登場人物がすぐに死亡する可能性が高まっていることを示します。パケット ヘッダーの DTH フラグをTCPに転送すると、セッションの物語がよりスムーズで魅力的なものになる可能性があります。

• M. Basaglia; J. Bernards; J. Maas (2023 年 4 月 1 日)。Concat 表記法。独立した投稿。doi : 10.17487 / RFC9402。ISSN 2070-1721。RFC 9402  。 情報提供。

最後に、猫とコンテナ（毛糸玉も含む）間のやりとりを適切に記述するための形式化された方法（ABNF 文法記述を使用）を示します。

• C. GPT (2023 年 4 月 1 日)。RL Barnes (編)。AI 皮肉検出: AI を不快にさせずに侮辱する。独立投稿。doi : 10.17487 / RFC9405。ISSN 2070-1721。RFC 9405  。 情報提供。

AI 皮肉検出プロトコル (ASDP) は、AI システムで皮肉を検出するためのフレームワークです ( ChatGPTの助けを借りて作成)。皮肉を検出することで、AI と人間の相互コミュニケーションが向上する可能性があります。

• M. Blanchet (2024 年4月 1 日)。Faster Than Light Speed Protocol ( FLIP)。独立投稿。doi : 10.17487/ RFC9564。ISSN 2070-1721。RFC 9564  。 情報提供。

大規模言語モデルなどの人工知能 (AI) の最近の進歩により、インターネット用の光より高速なプロトコル (FLIP) の設計が可能になりました。FLIP は、AI を使用して受信ピアに到着する前に将来のパケットを予測することにより、輻輳を回避し、セキュリティを強化し、インターネット上でより高速なパケットを配信する方法を提供します。このドキュメントでは、プロトコル、そのさまざまなカプセル化、およびいくつかの運用上の考慮事項について説明します。

• V. Cerf (1973 年1月 21 日)。PARRY が DOCTOR に遭遇。ネットワーク ワーキング グループ。doi : 10.17487 /RFC0439。RFC 439 。 不明。NIC 13771。

統合失調症の チャットボット PARRYとコンピューターシミュレーションの 精神科医 ELIZA (別名「ドクター」)の会話の記録。両者ともチューリングテストに見事に失敗しました。

• DL Covill (1973 年 6 月 22 日). R. Merryman (編). ARPAWOCKY. ネットワークワーキンググループ. doi : 10.17487/RFC0527 . RFC 527. ステータスは不明です。

ルイス・キャロルのナンセンス詩「ジャバウォッキー」の非常に「ARPA風」なパロディ。

• V. Cerf (1985 年 12 月)。「スタートアップ前の夜」。ネットワーク ワーキング グループ。doi : 10.17487 / RFC0968。RFC 968。 ステータスは不明です。

新しいネットワークを運用する際に発生する問題と、使用されるデバッグ手法について論じた詩。配列のインデックス付けは昔から問題があったことを示しています。

• B. ハンコック (1995 年 12 月)。クリスマス前の 12 日間のテクノロジー。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1882。RFC 1882 。 情報提供。

クリスマスキャロル「クリスマスの12日間」のパロディ。普通の日と同じように、コンピューターの問題が山積みになり、IT スタッフが大忙しになります。

• R. Glenn、S. Kent (1998 年 11 月)。NULL 暗号化アルゴリズムと IPsec での使用。ネットワーク ワーキング グループ。doi : 10.17487 / RFC2410。RFC 2410 。 提案された標準。

NULL 暗号化アルゴリズムを導入すると、数学的にはID 関数NULL ( b ) = I ( b ) = bとして定義され、カプセル化セキュリティ ペイロードが認証と整合性を提供する手段が提供されますが、機密性は提供されません。

RFC 編集者は、一般の人々から適切な形式のエイプリルフール RFC の提出を受け付け、4 月 1 日の 2 週間前までに受け取った場合は、その年の公開を検討します。^{[6] [7]}エイプリルフール RFC を公開するこの習慣は、RFC 作成者向けの指示メモで明確に認識されており、冗談めいた注意書きとして「過去数年間、RFC 編集者は 4 月 1 日の日付で真面目な文書を公開することがあったことに注意してください。テキストを読んで風刺と見分けられない読者は、マーケティングの将来があるかもしれません。」と書かれています。^[6]

• RFC エディターのホームページ – 個々の RFC をホストします

• Marsan、Carolyn Duffy (2005 年 4 月 1 日)。「Yet Another Foolish Network Protocol」。Network World– RFC 3751 およびエイプリルフールの RFC 全般について。
• リモンチェッリ、トーマス A.、ピーター H. サルス (2007)。エイプリルフールの RFC 完全版。ピアツーピア通信。ISBN 978-1-57398-042-5。