KDOC 274: 『RFCの読み方』

この文書のステータス

  • 作成
    • 2024-11-11 貴島
  • レビュー
    • 2024-11-16 貴島

概要

『RFCの読み方: インターネット技術の公式仕様書』はRFCの読み方を解説する本である。

メモ

  • RFCはけっして削除されることはない(p19)
  • 基礎を学ぶのに最適なRFC1178。コンピュータの命名方法
    • つけてはいけない名前の例
    • おすすめのつけかた。テーマのある名前をつけること。あまり使われない、数の多いものだとなおよい。色、神話上の人物の名前、元素名、など
  • セキュリティに関する考察はRFCでは必須のものとされている。なのでエッセイのRFCであっても章は存在する(p70)
  • ユーザーエージェント(メーラー)からメールを送るときには、直接宛先のメールサーバではなく、SMTPサーバに送るのが一般的である。送信待ちとなるのを防いだり、再送機能を利用するためにSMTPに任せる(p89)
  • 1回読んでわかりにくかったときは、箇条書きにして文を細かく分けて考えるとよい(p89)
  • 待機と接続の確立(p91)
    • 「待機(listing)」ポートを開きそこへの接続を待つこと。TCP/IPの通信ではコンピュータは1~65535までの番号が付いたポートを持っている
    • POP3は110番ポートを開きそこでの接続されるのを待つ
    • クライアントは自分自身のポートのうち未使用のポートを開き、そのポートとサーバ側の110番をつなげようとする。こうしてクライアントのポートからサーバの110番ポートのデータが流れるようになった状態が「接続の確立」である
    • この時点ではまだ声が聞こえるにすぎず、会話にはなっていない
  • キーワードは3~4文字で、引数は40文字以下でなければならない(p94)
    • ここから言えるのは、「 こちらから 送る引数は40文字以下でなければならない」である。けっして「 相手から 送られる引数は40文字以下である」ではない
  • 「大文字で送らなくてはならない」とあっても、相手が必ず守っているという前提は避けなければならない(p95)
  • 「POP3の認証のメカニズムは1種類だけでなく、すべてのPOP3サーバに要求される唯一の認証メカニズムは存在しない。少なくとも1種類の認証メカニズムをPOP3サーバはサポートしなくてはならない」認証プロトコルは将来的に変わりうるもので、自由度をもたせて変更に対応していこうということ(p105)
  • 一般にサーバ側に「どちらでもよい」という定義があれば、クライアント側は「どちらにも対応しなければならない」ということになる(p107)
  • 1バイトが何ビットなのかはCPUのアーキテクチャに依存する(p109)
  • さまざまなCPU間でもやりとりを前提とする通信プロトコルでは、特定CPUに依存することなくビット数を正確に表すために、オクテットの表記を利用することが多い(p108)
  • 「ここでは、各メッセージの順番は定義されていない」クライアントでは順番を前提にしてはならない(p119)
    • 規定がないことも読み取る。暗黙の前提と考えてはいけない
  • コマンド例
    • STAT: メッセージがあるかどうか
    • LIST: サーバにあるメッセージ番号の一覧
    • RETR: メッセージ内容を取得する
    • DELE: 削除マークをつける。POP3 セッションが UPDATE 状態になるまで、実際の削除はしない
    • NOOP: POP3サーバは何もせず、単に成功のメッセージを返す
    • RSET: DELEコマンドに対して取り消しを行う
    • QUIT: 処理状態から更新状態に遷移する
  • NOOPの使いどころ。レスポンスを返さずに10分経過したときにPOP3サーバはオートログアウトが認められている。接続を保持したい場合は何かしらのコマンドを発行する必要がある。そのとき、STATやLISTコマンドでもいいのだが、負荷をかけてしまう。そういう場合に負荷をかけないようにNOOPを用いる、などができる(p124)
  • 最低限実装しないといけないコマンドと、オプションコマンドがある(p133)
  • 存在しないメールアカウントの場合にも成功の合図を返してもよい。有効なユーザ名かどうかを判別されるのを防ぐため。UNIXのログインも同様のポリシーで、存在しないアカウント名でもパスワードを尋ねられる(p143)
  • 過去に読んだことのあるメールかどうかはUIDLコマンドでユニークIDを取得し、取得済みのメッセージと比較を行えばよい
  • RFCのヘッダを見て広く利用されているものを見る。洗練されている可能性が高い。用意されているコマンドはどれも必要なもので、意味不明なものはあまりないと予測できる、という(p165)
  • 目次を見てメインとなる部分を予測しそこから読み始める。そこだけでわからなかった内容を目次の項目から見つけ出し、拾い読みしていけばよい。最後に全体を始めから読み直してみるとよい、とよい(p165)
  • RFCは抽象的な記述が多い。大切な記述を見逃す可能性がある。したがって例示やセッション例などの具体例を参考にし、「これはどういう意味か」と考えながら読んでいくとよい。「自分だったらどうするか」というふうに想像力を働かせながら読み勧めるのがコツである、という(p165)
  • ジョークRFCの世界(p166)
    • 1149
    • 748
    • 1926
    • 2100
    • 2550
    • 3514
  • RFC2234: 標準化されたBNFであるABNFを規定する(p172)
  • BNFと、一般的な文章の文法を説明する場合と異なるのは「規則」と「規則の内容」をどちらを先に記述するか、である(p174)
    • 一般的な文章: 五・七・五の音からなる文を俳句と呼ぶ
    • BNF: 俳句を五・七・五の音からなる文と定義する
    • BNF: 俳句 = 五・七・五の音からなる文
  • 自由書式では、通常すでに世の中にあるものを説明するように記述できる。しかしBNFの場合は何もない状態から規則を1つ1つ作り上げ、それに名前をつけていくことになる(p175)
  • BNFを理解するうえでもっとも重要なのは、「名前を付けていく作業の繰り返し」という考え方である(p175)
reader = "Kijima"
  • リテラルとはプログラムのソースコードで定義される定数のことである。たとえば「name」というリテラルの文字列があった場合、これは「name」という文字列であって、決して「名前」を意味するわけではない。つまり「n」「a」「m」「e」という文字が連続して並んでいるだけである(p180)
"ren" [ "ame"]

version = "95" / "97" / "2000" / "XP"
office = "Microsoft Office" version
  • RFC 2234 でBNFのコア規則をBNFで表現している。汎用的に利用できることを前提にしている
  • p205あたりの、BNFの演算子をBNFで説明するところがよくわからなかった。概念が定着してから再度読み直す必要があるだろう
  • <> の散文的表現の意味がわからない
cal 1752

                            1752
      January               February               March
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
          1  2  3  4                     1   1  2  3  4  5  6  7
 5  6  7  8  9 10 11   2  3  4  5  6  7  8   8  9 10 11 12 13 14
12 13 14 15 16 17 18   9 10 11 12 13 14 15  15 16 17 18 19 20 21
19 20 21 22 23 24 25  16 17 18 19 20 21 22  22 23 24 25 26 27 28
26 27 28 29 30 31     23 24 25 26 27 28 29  29 30 31


       April                  May                   June
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
          1  2  3  4                  1  2      1  2  3  4  5  6
 5  6  7  8  9 10 11   3  4  5  6  7  8  9   7  8  9 10 11 12 13
12 13 14 15 16 17 18  10 11 12 13 14 15 16  14 15 16 17 18 19 20
19 20 21 22 23 24 25  17 18 19 20 21 22 23  21 22 23 24 25 26 27
26 27 28 29 30        24 25 26 27 28 29 30  28 29 30
                      31

        July                 August              September
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
          1  2  3  4                     1         1  2 14 15 16
 5  6  7  8  9 10 11   2  3  4  5  6  7  8  17 18 19 20 21 22 23
12 13 14 15 16 17 18   9 10 11 12 13 14 15  24 25 26 27 28 29 30
19 20 21 22 23 24 25  16 17 18 19 20 21 22
26 27 28 29 30 31     23 24 25 26 27 28 29
                      30 31

      October               November              December
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
 1  2  3  4  5  6  7            1  2  3  4                  1  2
 8  9 10 11 12 13 14   5  6  7  8  9 10 11   3  4  5  6  7  8  9
15 16 17 18 19 20 21  12 13 14 15 16 17 18  10 11 12 13 14 15 16
22 23 24 25 26 27 28  19 20 21 22 23 24 25  17 18 19 20 21 22 23
29 30 31              26 27 28 29 30        24 25 26 27 28 29 30
                                            31
  • グレゴリオ暦を導入する前の日付はグレゴリオ暦で表現できないことがある
  • 時刻と時間を明確に区別する。時刻はある瞬間を指し示す(p228)
  • RFCの要求レベル(必須、推奨、任意…)を表すキーワードはRFC 2119で定義されている
  • 最初に文書で0年〜9999年と仮定すると明記されている。紀元前や10000年は考慮から外している
  • うるう秒が挿入される際は、59→60→00秒となる。うるう秒はうるう年の2倍以上の頻度で挿入されるので考慮する必要がある(p261)

関連

なし。