要約

  • Dateはcreatorがmessageを完成し、配送へ渡せると判断した時刻であり、実際にtransportされた時刻ではない。
  • Netnews relayは既知のMessage-ID履歴を有限に保つ必要がある。執筆時刻でstale判定すると、遅れて投入された新着記事まで古い再送として拒否しうる。
  • Injection-Dateは最初のDateを変更せず、network entryの時刻を追加した。ただし作者、時計の正確さ、各serverへの到着を証明するものではない。

月曜日の原稿が金曜日に現れる

通信できない場所で記事を書き終えたとする。applicationは月曜日のDateを付けるが、posting agentがnews serverへ届けられるのは金曜日だった。

作者にとって月曜日は正しい。文章を完成させた日時だからだ。しかし有限のhistory databaseを運用するrelayにとって、古い日時は別の危険に見える。Message-IDの記録を削除した後に、以前の記事が経路を巡って再び来たのかもしれない。

月曜日を金曜日に書き換えれば通りやすくなるかもしれないが、作成履歴を偽る。月曜日を残せば、古い実装は投入直後の記事をstaleとして落とすかもしれない。一つのfieldがcreation recordとadmission evidenceを兼ねたことが、矛盾を作った。

Netnewsは第一の日付を訂正せず、第二の日付を隣に置いた。

Dateが守っていた出来事

1987年のRFC 1036は、以前Postedと呼ばれたDateを、messageがnetworkへ最初にpostされた日時と説明し、propagation中に変更しないよう求めた。途中のsystemが自分の時刻で起点を更新しないための安定した線だった。

RFC 5322はorigination dateをさらに限定した。creatorがmessageを完成し、delivery systemへ入れられると示した時刻であり、実際のtransport時刻ではない。offlineのportable computerでqueueに入れ、後から接続する例では、日時はqueue時点に属する。

この意味は作者側の履歴を保存する。一方で、network entryを判断する根拠としては弱い。端末時計はずれうるし、入力が誤りや虚偽の場合もある。正確でも、長い待機の前に作られる。誠実なDateほど、relayの質問には答えていないことがある。

重複防止には記憶の期限があった

Netnewsでは複数のrelaying agentとserving agentが記事を交換する。RFC 5537は、すでに見た記事を記録し、同じ記事の再提示を拒否するよう求める。Message-IDが比較のkeyになる。

すべてのIDを永久保存すればhistoryは無限に増える。そのためprotocolはcutoff intervalを認める。期間より古い記事を拒否できれば、その古いID記録も捨てられる。後で戻ってもdate checkが止めるからだ。RFCはUsenetの慣行として少なくとも7日を挙げるが、propagation時間より短いcutoffは未受信記事を拒否すると警告する。

dateはduplicateの証明ではない。duplicateを見分ける証拠をいつまで保持するか決める材料だ。短い期間はresourceを早く戻すが、遅延した正当な到着を失う。長い期間はslow pathを守るが、storageとlookupを増やす。

composition timeしかなければ、記事がnetwork外にいた時間までnetwork ageへ加算されてしまう。

第二の時計に与えた狭い権限

RFC 5536はInjection-Dateを、記事がnetworkへinjectされた日時と定義した。stale checkでuser agentのcomposition timeではなく、news serverがinjection時に付けた時刻を使えるようにすることが目的である。

injection時にはfieldを追加しなければならない。ただし以前のsoftwareとの互換性から、fieldのない記事も受理しなければならない。ない場合はRFC 5537の判断がDateへfallbackする。新旧双方を運ぶことで、一斉切替なしに意味を増やした。

重要なのは、第二のfieldが第一を書き換えないことだ。RFC 5536は既存のDateを変更してはならないとする。agent間の時計は同期していないため、Injection-Dateが数値上はDateより前になることさえある。二つの差は便利な観測であって、完全な因果証明ではない。

このfieldは、使われていたものの文書化されていなかったNNTP-Posting-Dateを置き換え、旧名はdeprecatedとなった。標準化は語彙を共有したが、全時計を同期させたわけではない。

三番目の時刻はserverだけのもの

RFC 5537の一般的なhistory最適化では、Injection-Dateがあればそれをarticle dateとし、なければDateを使う。relayとserverは未来に過ぎる値を検査し、cutoff方式なら保持期間との比較にも使う。

別の方式は、そのserverが最初に見た時点からhistory recordをexpireさせる。RFCが示す方式では、future dateの許容誤差に備えてretentionをcutoffより少なくとも24時間長くする。ここでlocal first-seenという三番目の視点が現れる。

RFC 3977はNNTP serverのarrival timestampを定義し、その順でlocal article numberを割り当てる。これは一つのserverが観測した時刻であり、最初のinjectionでも作者のcompletionでもない。

  • Dateはcreatorの完成宣言を保存する。
  • Injection-DateはNetnewsへのentryを示す。
  • arrival timeは特定serverの受信とlocal orderingを示す。

三つを一つにすると、経路遅延が作者の遅延に見え、offline待機がnetwork再循環に見える。

複数入口でも年齢を増やさない

冗長性や分離networkのため、同じ記事を複数のinjecting agentへ渡すことがある。目的は複数記事の作成ではない。経路が合流した時、同じMessage-IDとして一度だけ受理されるべきだった。

そのためRFC 5537は、すべてのproto-articleでMessage-ID、Date、Injection-Dateを同一にするよう求める。すでにinject済みの記事を別networkへ再投入する形へ戻す場合も、三つを変更せず保持する。入口ごとに現在時刻へ更新すれば、同じ記事が何度も若返る。

Injection-Dateは後続gatewayが自由に押す「いま」のstampではない。multiple injectionでは、一つのpublication historyを複数入口で共有するための安定した値になる。

古い判断は互換性として残った

旧実装は新fieldを無視し、Dateでstale rejectionを続ける。RFC 5537は、compositionが大きく過去なら、正しいInjection-Dateがあっても古いserverでpropagationが悪化しうると認めている。

Message-IDとDateがすでにある場合、posting agentはcompositionから1日以上なら第二の日付を追加することが推奨され、複数投入なら必須になる。injecting agentは過度に未来または過去の値を調べ、条件に従ってcurrent timeを追加する。posterに近い境界なら、拒否理由をまだ返しやすい。

それでもdownstreamの旧softwareは変わらない。互換性は通信を継続させる一方、同じ記事から異なる判断が生まれる移行期間も受け入れた。

標準fieldは時刻証明書ではない

Injection-Dateはentry agentの時刻表明であり、cryptographic signatureでもauthorsip proofでもない。同期精度を保証せず、moderation、読者の閲覧、全serverへの到着、local retentionの削除時刻も示さない。

現在のIANA Message Headers RegistryはInjection-DateをNetnewsのstandard fieldとして掲載し、RFC 5536を参照する。登録は名前を安定させる。個々の値の真実性や全実装へのdeploymentを保証しない。

歴史的な価値は、この狭さにある。creatorの時刻を残し、network entryには別の観測を加え、各serverにはlocal arrivalを持たせた。第二の日付が第一を消す権限を持たなかったからこそ、判断は正確になった。