要約

  • RFC 3085は、提供者のドメインと日付を含むURNで一つのNewsML NewsItemを複数のURLから区別し、正の改訂番号で同じ項目の版を順序づけた。
  • UとAは異なる更新ケースを表す。しかし、識別子の登録も改訂番号も、対象の存在・検証可能性・取得可能性を証明しない。

訂正記事が配信網を回ると、配信元は旧URLを残し、顧客は別の場所にコピーし、アーカイブにはさらに別の版が入る。読者が指す「その記事」と、データが置かれた場所は同じではない。RFC 3085のURNは、この二つを分けて扱うための仕組みだった。

2001年3月のRFC 3085は、NewsML NewsItem向けにnewsml名前空間を提案した。同じ論理項目が複数の物理的な場所に存在しうるため、NewsMLでは複数のURLを持ててもURNは一つとする。そのURNが場所に依存しない項目名を担う、という設計である。ただしRFCの区分はInformationalで、本文もインターネット標準を定めるものではないと明記している。

文字列には提供者のドメイン、日付、NewsItem ID、改訂番号、そして任意の更新文字が含まれる。割当主体は指定日にそのドメインを所有していなければならない。同じ提供者と日付の組み合わせではNewsItem IDが一意である必要がある。改訂番号は正の整数で、0は不可。同じ項目なら大きな番号がより新しい版を指す。これはニュース全体の時刻表でも、版の発行間隔でもない。

末尾の文字は編集上の変化を区別する。NewsItemにUpdate要素が一つでもあればUを使う。置き換えるのがNewsManagementデータだけならAを使い、どちらでもなければ文字を付けない。本文の更新と管理情報の差し替えを同じ状態として扱わないための規則だ。

語彙上の同値性について、RFCはProviderId、DateId、NewsItemId、RevisionIdの四つを大文字小文字を区別せずに比較すると記している。任意の更新文字はその列に入っていない。したがって本文から言えるのは、更新文字が同値判定の追加フィールドとして挙げられていない、という限定的な点までだ。末尾だけ異なる識別子を各実装がどう扱ったかまでは分からない。

URNはニュース本文へのリンクそのものではない。RFC 3085は、妥当な組み合わせに対する解決サービスと検証サービスを、提供者が用意する場合の責任として記す。現在のIANA正式URN名前空間登録簿にはRFC 3085を参照するnewsmlが載っているが、それは登録の証拠であって、稼働中のリゾルバーの証拠ではない。RFCの例も実際の資源を指すとは限らないと断っている。

IPTCの現在のNewsML-G2紹介は、個別ニュース項目やマルチメディアのパッケージ交換が後の規格でも扱われたことを示す。ただしNewsML 1.0の採用やRFC 3085のリゾルバー運用を裏付けるものではない。このRFCが分けたのは、項目の識別、版の順序、そして内容の取得という別々の仕事だった。

分析

この設計は「どの項目か」と「どの版が後か」を分離する。ドメインと日付は割当空間を、ローカルIDは一つの項目を、改訂番号はその項目の版順を示す。規則が定義されていることと、流通したコピーが実際にその順序を保つことは別の事実である。

UとAも同様だ。更新要素を含むNewsItemと、管理メタデータだけを差し替えるケースは違う。しかし印が示すのは規定された分類であり、受信者が通知を受け取ったことや、最新のコピーを持つことではない。

監視

アーカイブや配信サービスを確かめるなら、構文、指定日におけるドメイン所有、項目IDの一意性、改訂順、更新文字と内容の対応、現在の解決応答を別々に検査する。RFCは可用率、鮮度、配信保証を定めていない。

「新しい改訂が記録されたのに取得できるコピーがない」と「URLは応答するが古い版を返す」は異なる障害である。IANA登録は運用実態を示さず、NewsML-G2も後続の文脈にとどまる。

制御とインセンティブ

URNを割り当てる提供者が、その提供者/日付の範囲でIDの一意性を管理し、解決サービスを運営するかどうかを決める。受け手の報道機関はコピーや索引を持てるが、それだけで元の改訂番号を割り当てる主体にはならない。

編集組織は、URNの保存にとどめるか、リゾルバー、リダイレクト、ミラーなど検索経路まで維持するかを選ぶ必要がある。後者には保守責任が伴う。名前だけではファイルの所在は保証されない。

カタログだけが残り、本文が消えると、版順から欠落を特定できても復元はできない。項目、改訂、所在、検証、実際の配信記録は分けて保持したい。

出典