要約

  • RFC 867はDaytimeのポート、転送、応答終了を定めたが、日付には特定の構文がないと明記した。二つの例は必須形式ではない。
  • 機械で使える時刻については、固定32ビット値を返す別のTime Protocolへ明示的に案内した。欠落ではなく役割分担だった。
  • 後年の時刻表現は4桁年、UTCとの関係、狭い文法を定めた。Daytimeは、見て分かることと意味が相互運用できることの違いを示す。

どちらも正しいのに一つの読み方がない

ある応答は Monday, February 22, 1982 17:37:43-PST、別の応答は 02 FEB 82 07:59:01 PST と書く。人なら日付だと分かる。ソフトウェアには追加の方針が必要だ。年は2桁か4桁か、ゾーンの前はハイフンか空白か、曜日と日付が食い違ったらどちらを採るのか、月名は英語だけなのか。

RFC 867は二つの書式を「よく使われる」例として挙げただけで、その直前にDaytime固有の構文はないと述べた。一つの例だけを読むパーサーは、観測した実装の慣行を読んでいる。RFC 867という普遍的な日付文法を実装しているわけではない。

ここではネットワークの成功と意味の成功が分かれる。TCP接続も終了も正しく、UDPの応答も届き、文字集合も推奨範囲に入っている。それでも、複数の独立したクライアントが同じ瞬間へ変換できるという保証はない。

二ページが決めた範囲

1983年5月のRFC 867は、Daytimeをデバッグと測定に役立つ道具とした。TCPでは13番ポートで待ち、接続後に現在の日付と時刻をASCII文字列で送り、受信データは捨て、送信後に閉じる。UDPでも13番ポートを使い、データグラムを受けると内容を無視して現在時刻の応答を返す。

出力には印字可能なASCII、空白、復帰、改行を使い、一行にすることが推奨された。端末や単純な検査ツールで見やすく、クライアントも応答のまとまりを扱いやすい。

一方で、フィールド順、区切り、秒以下、4桁年、UTCオフセット、閏秒、言語、時計精度、出所証明は決めていない。「現在」はサーバーの主張であって、同期や正確さを証明しない。ASCIIはバイトを制約しても、日付の意味を一意にしない。

登録ポートも同様だ。13番という共通名札は期待するサービスを識別するが、運用者に世界時の権威を与えず、アルファベットのゾーン略号を一意にしない。

機械には37番ポートが用意された

RFC 867の末尾は、機械で使う時刻にはRFC 868のTime Protocolを使うよう指示する。Timeは37番ポートで、1900年初頭からの秒数を32ビット符号なし値として返した。Daytimeは13番で読める一行、Timeは37番で固定長の数量を返す。

したがってDaytimeを未完成の時刻同期方式とみなすのは誤りだ。人が簡単な接続で遠隔ホストの応答と時計表示を確かめる用途と、プログラムが計算する用途を意識して分けていた。

1983年10月のRFC 880ではDaytimeはelective、つまり実装してもしなくてもよいプロトコルだった。Timeはrecommendedで、全ホストに実装が勧められた。この歴史的区分は現在の普及率を示さないが、当時の優先順位を記録している。

固定数値にも人向け表示や時代番号の問題が残る。ここで2036年やNTPのera unfoldingを繰り返す必要はない。RFC 868は、RFC 867自身が示した機械用の対照としてのみ扱う。

曜日と日付が争った例

RFC 867の最初の例は、1982年2月22日を火曜日と書いていた。実際は月曜日で、RFC Editorは2025年にerratum 8551を検証し、TuesdayをMondayへ直した。これは編集上の訂正であり、プロトコル変更でも実装調査でもない。

しかし、重複情報の弱点を具体的に示す。曜日と完全な日付は同じ暦の事実を二度表すため、互いに矛盾できる。人は違和感を持てるが、機械は優先規則を必要とする。Daytimeは解析規則そのものを持たないので、衝突の決め方も持たない。

RFC 3339は後にインターネットのタイムスタンプを設計する際、この種の危険を明文化した。曜日は日付と一致しない可能性があるため除外し、生成側には4桁年を求め、UTCとの関係を数値オフセットまたはZで示すようにした。曖昧なアルファベットのゾーン名にも依存しない。

両者に直接の改訂関係があるわけではない。RFC 3339はRFC 867を廃止せず、2025年の訂正が2002年の文書を生んだはずもない。比較できるのは設計の置き場所だ。Daytimeではサーバーが表示を選び、RFC 3339ではワイヤ形式を固定してクライアントが表示を選ぶ。

人向け出力が密かなAPIになるとき

読みやすさはデバッグ費用を下げる。RFC 3339もその価値を認める。ただし国ごとに自然な日付順は異なる。世界規模の交換形式を画面表示だけに任せることはできない。

Daytimeを人が眺める限り問題は小さい。監視スクリプトが一行を取り込み、特定サーバーに合わせた正規表現で時刻へ変換した瞬間、句読点や語彙が非公開APIになる。運用者が表記を変えてもRFC 867には適合したままだが、スクリプトは壊れる。

これはサーバーの違反ではない。利用者が一度の観測を、標準が与えなかった永続保証へ昇格させた結果である。防御可能な自動化は原文を不透明な証拠として保持するか、別途、明示的な文法とタイムゾーン規則を合意しなければならない。

IANAの登録は公開命令ではない

IANAは現在もTCP/UDP 13番をdaytimeとして登録し、RFC 867を参照している。これは名前空間の証拠であり、稼働、正確性、安全性、公開の必要性を証明しない。

UDP版は現代的な露出判断を必要とする。要求内容を読まずに応答し、IP送信元は偽装できる。RFC 8085は一般に、短い未認証要求が大きな応答を生むサービスは増幅に悪用され得るとして、送信者確認や応答制限を勧める。Daytimeの現在の悪用件数や一律の増幅率は資料からは分からない。

運用者が問うべきは「標準ポートか」ではなく「なぜ到達可能で、応答にどの権限を与えるか」である。TCPの確立は時計を認証せず、UDPの送信元は依頼者を認証せず、読みやすい文は時刻を認証しない。

小さな標準が止まった場所

RFC 867は接続、応答、終了を予測可能にし、出力を人が読みやすいまま残し、機械文法を約束しないと明確にした。その抑制が重要である。

個別の応答を読むコードは書ける。だが標準が、そのコードは全ての適合サーバーと将来の変更で動くと保証しているかは別問題だ。Daytimeにはその保証がない。

相互運用性は一枚ではない。ポートが共通でも日付文法は共通でない。文字が妥当でも瞬間は曖昧になり得る。サーバーが適合していても自動化は失敗する。標準を理解するとは、規定された機能だけでなく、規定しなかった推論を知ることである。

出典と証拠の限界

Daytimeの規則はRFC 867、例の訂正はRFC Editorのerrataによる。機械向けの対照はRFC 868、歴史的地位はRFC 880にある。

後年の設計比較はRFC 3339、ポート管理はRFC 6335とIANAレジストリ、UDP運用境界はRFC 8085を用いた。現在の配備、精度、攻撃頻度を示す資料ではない。