【RFCの読み方-番外編】ジョークRFCの読み方
4月1日は、エイプリルフールですが、この日は各業界で本気とも冗談ともつかないようなネタがインターネット上で氾濫します。IETFでもやはりエイプリルフールには、「ジョークRFC」というものを発行しています。
たしか2021年のジョークRFCは、RFC8962の１件だけだったように記憶しています。今年もはたしてジョークRFCは発行されるのでしょうか？
今回は、来たるべき今年のエイプリルフールに向けてジョークRFCについて解説します。
ジョークRFCとは
【RFCの読み方】RFC文書を読むときの前提知識でも少しふれましたが、ジョークRFCとは主に4月1日に公開されるユーモラスなRFCのことです。ナンセンスな内容を本来のRFCと同じフォーマットでおおまじめに書かれているので、著者の意図が理解できれば面白いです。とはいえ、もとの技術を理解している前提で書かれているため、正直どこがジョークなのか？と思ってしまうものもあります。
一番有名なものは、「鳥類キャリアによるIPデータグラムの伝送規格」でしょうか。日本でも人気がありますので、検索をすればたくさん出てきます。日本語でなぜこのジョークRFCが面白いかを解説しているサイトもありますので、興味がある方は検索してみてください。元のRFCは以下になります。
RFC1149 A Standard for the Transmission of IP Datagrams on Avian Carriers
RFC2549 IP over Avian Carriers with Quality of Service ←このRFCでRFC1149がアップデートされてます。
ジョークRFC6919を読んでみた
そんなに有名でなく、技術的にマニアックではなく、短めのジョークRFC6919を読んでみましたので、ご紹介したいと思います。
RFC6919 Further Key Words for Use in RFCs to Indicate Requirement Levels
日本語訳だと「要求レベルを示すRFCで使用するその他のキーワード」といったところでしょうか。
まずRFCのヘッダを確認します。ドキュメントソースは、"Independent Submission"となっています。これは、公式のIETF/IAB/IRTFプロセスの範囲外であるが、インターネットコミュニティに関連し、妥当なレベルの技術的および編集的品質を有するためRFCを公開したことを意味します。ジョークRFCの場合は、このドキュメントソースが指定されます。
RFC6919の要約
英語キーワードの使用方法について言及しています。【RFCの読み方】RFC文書を読むときの前提知識 と比較して読むとエンジニアの本音が垣間見えてきて面白いです。
一部を私の解釈で要約してみました。
- MUST(BUT WE KNOW YOU WON'T)
- しなければならない（しかし、我々はあなたが知らないことを知っている）
正式なレビュー基準を満たすために必要な要件を示すために使用される。そしてこの句はカッコが短縮された形でよく使用される。 - SHOUD CONSIDER
- 検討する必要がある
仕様の作成者が実装は何かを行うべきであると考えていることを示していますが、彼らは何をするのかよくわかっていない。 - REALLY SHOUD NOT
- 本当にすべきではない
ある重要なベンダーが今でも行っている危険な行為を示すもので、それゆえ「MUST NOT」にすることができなかった。 - OUGHT TO
- するべき
明らかに道徳的に正しい実装動作を楽観的に主張するものであり、したがって実証を必要としない。 - WOULD PROBABLY
- たぶん...だといいな
合理的な実装が与えられたケースで何をする可能性が高いかについての著者の予想を示す。実装が合理的であることは要求されていない。 - MAY WISH TO
- したいです
一部の人には魅力的に見えるかもしれないが、他の人にはばかげている、または不必要であると見なされている行動を示す。 - COULD
- たぶん...だろう
仕様の作成者が存在の可能性を明確にする方法を提供し、信頼性の高いまたは安全な操作に不可欠である可能性があるが、厳しい要件がないヒントを提供する。要件がないため、ベンダー製品の差別化が可能となる。 - POSSIBLE
- 可能です
ワーキンググループのメンバーの一部が決して起こり得ないこととして境界ギリギリのことを考えていたと示しているが、実際にはプロトコルは最も基本的なレベルで機能する。 - MIGHT
- たぶん...だろう
製品の差別化を促進するために、意図的に隠密な方法で要件を伝える。（「COULD」と比較参照） - 従来、IETFドキュメントのセキュリティ要件は、RFC2119のキーワードと上記で使用されているフレーズを組み合わせて表現されてきた。RFC2119のキーワードは、脅威と軽減策が明確で明確に定義されている場合には役に立つ。このドキュメントのキーワードは、脅威モデルがあいまいで、軽減策が不明確または不便な場合に適用できる。
あとがき
本内容を信じたことによるいかなる損害に関して、当社ならびに筆者は一切の責任を負いかねます。（笑）
国や言葉は違えど、共通する感覚はあったのではないでしょうか。興味があれば、ぜひ原文（英語）でトライしてみてください。本記事を通して、RFCをもっと身近に感じていただけたら嬉しいです。
日本はアメリカより時間が進んでいますので、今年のジョークRFCは4月2日くらいに判明するでしょう。面白そうだったら、また本ブログで取り上げたいと思います。
本ブログに対するご意見やご要望がありましたら、SYNESIS エンジニアノート お問い合わせページよりご連絡をお願いします。
