RFCの読み方

エンジニアノート

 

前回、標準化団体でIETFについて少し触れました。RFCはIEFTが発行している公開文書です。「質問する前にRFCを読みましょう」「仕様はRFCで確認しましょう」と言われたりしますが、そもそも慣れていないとRFCをどう読んだらいいかわかりません。今回は、RFCとはなにか、RFCの読み方などについて、私の経験をもとに解説したいと思います。

RFCとはなにか

RFC(Request For Comments)はインターネットで用いられる技術の標準化や運用に関する幅広い情報共有を行うために公開されるIETF文書シリーズです。インターネットの様々な技術的仕様、ルール、情報、TIPSを公開しています。

文書のステータス

文書は一度公開されると基本的には変更できませんので、文書の現在のステータスは必ず確認するようにします。

Category 説明
Standards Track INTERNET STANDARD 国際標準とすべき仕様の最上位。STD番号が割り振られる。
(DRAFT STANDARD) RFC6410によって削減された。ただし、古いRFCではまだこのCategoryのものは存在。
PROPOSED STANDARD 複数の組織での独立な実装と、それらの相互接続性が確認されているもの。
EXPERIMENTAL 標準化が目的ではない調査や検討などを含む文章。特定の企業が自社の仕様を公開する際にも用いられる。
INFORMATIONAL 標準化が目的でない情報提供が目的の文章。公式度が低い前提。
HISTORICAL 標準化の過程がわかるよう、過去の議論を残すための文章。
BEST CURRENT PRACTICE 現時点での最良の実践。IETFが支持する技術的関連情報を発行するためにRFC1818(BCP:1)で定められた。BCP番号が割り振られる。
UNKNOWN 1990年以前のRFCのうち、未分類のもの。

RFC 編集者の公表している正誤表もあります。こちらも合わせて確認します。

RFC ERRATA(別ウィンドウ・外部リンク)

RFCの英語

RFCは英語で公開されています。日本語訳のサイトもありますが、機械翻訳をしている場合が多いため、意味がよくわからない場合があります。比較的かんたんな英語(IEEEやITUに比べて、ですが)ですので、原文のままで一度チャレンジしてみてもよいかもしれません。

原文のままで読まれる際は、最初にRFC8179を読んでみるとRFC独特の英語が理解できます。要約するとこんな感じです。

MUST,REQUIRED,SHALL
その規定が該当仕様の絶対的な要請事項
MUST NOT,SHALL NOT
その規定が該当仕様の絶対的な禁止事項
SHOULD,RECOMMENDED
特定の状況下では特定の項目を無視する正当な理由が存在するかもしれないが、異なる選択をする前に該当項目の示唆するところを十分に理解し慎重に重要性を判断しなければならない
SHOULD NOT,NOT RECOMMENDED
特定の動作が容認できるないし非常に有用であるというような特定の状況下では正当な理由が存在するかもしれないが、このレベルの動作を実装する前に該当項目の示唆するところを十分に理解し重要性を判断しなければならない
MAY,OPTIONAL
ある要素が選択的であることを意味する。その要素を求めている特定の市場、ベンダーはその要素を提供しないだろうが、その製品機能を拡張すると察知して、その要素を含む選択をベンダーがあるかもしれない。その選択事項(オプション)を含まない実装は、おそらく機能的に劣ることになるがそのオプションを含む他の実装との相互運用に備えなければならない(MUST)、同様に特定のオプションを含む実装は、そのオプションを含まない実装との相互運用に備えなければならない(MUST)
これらの語句は全て大文字の場合のみ、この文書で定義された特別な意味をもつ 、小文字の場合は通常の英語の意味をもち、この文書の影響はない。

RFCリーダー

以前は、IETFのサイトのRFCは読みづらく、探しづらかったのですが、RFC Editorの登場により随分読みやすくなりました。ステータス別の検索等も可能です。
RFCリーダーは、他にもいろいろ存在します。私は10年前くらいから、RFC Readerというサイトを利用しています。ログイン機能があり、コメントもかけるため大変重宝しています。

RFC Reader(別ウィンドウ・外部リンク)

これらをふまえて言えること

いろいろ書きましたが、RFCは、仕様に限らず様々なインターネットの事柄を記述しています。なかには、ジョークRFCなんてものも存在します。慣れないうちはなかなか必要な情報にたどり着くことができませんでしたが、二次ソース情報(書籍、テックブログ、セミナーなど)も併用して、慣れていくことが重要だと考えます。

関連記事